What "Fulfilled by Acumatica" actually means

Acumatica publishes the criteria itself. Its blog post on the programme, dated 14 March 2023 and read on 20 August 2026, says Fulfilled by Acumatica partners are "hand-selected and carefully screened", must "have 10 (or more) satisfied mutual customers", and must commit to the Always Current programme, which the same post describes as automatically updating the application monthly and upgrading it semi-annually.

The commercial mechanic is the part that gets least attention and matters most to a partner. Fulfilled by Acumatica applications appear on Acumatica’s own price list, which means the customer can buy the application from Acumatica in the same transaction as the ERP, and the application can be bundled with core Acumatica modules and editions. Your client signs one paper instead of two, and the renewal arrives on one invoice instead of two.

There are supporting commitments as well. The same post lists guarantees the vendor gives about integration quality, about not degrading Acumatica’s performance, about data consistency, about the app being built by Acumatica-certified developers, and about meeting security requirements.

Read as a whole, the programme is Acumatica taking on the billing relationship and, in exchange, holding the vendor to an installed base and an update cadence. That is a real thing and it is worth something. It is a different thing from Acumatica warranting that the application will do what your client needs.

Certification is where the technical review lives, and it is not optional. To list on the Acumatica Marketplace a vendor needs ADN Level 2 or higher, and on Acumatica’s own community an Acumatica staff member listed the Level 2 requirements as technical certification of the solution, Acumatica University training and badging for the development team, and an ongoing Always Current commitment requiring re-certification within 90 days of a major release. So every application you can see in the Marketplace has been through certification, which makes the certification badge a floor rather than a distinction.

What certification checks is set out in Acumatica’s ISV Software Certification Guidelines. An Acumatica test engineer deploys a clean instance, imports the customization, runs static code analysis with Acuminator, and runs functionality verification tests. The guidelines cover naming prefixes and framework conventions, TLS 1.2, encryption of stored credentials, PCI DSS where payments are handled, web services API guidelines including a limit on records returned per call, installation and upgrade documentation, and a requirement that the solution does not degrade Acumatica ERP performance.

Now compare that with what Fulfilled by Acumatica adds. The published FbA requirements are an installed base of 10 or more mutual customers, the Always Current commitment, the commercial arrangement, and a set of guarantees the vendor gives. We could not find a published Acumatica statement that Fulfilled by Acumatica involves a deeper or additional code review beyond certification. If one exists, we have not seen it, and we would change this page if someone at Acumatica pointed us at it.

The honest read for a partner is this. Certification tells you the application is built the way Acumatica wants applications built and does not break the platform. Fulfilled by Acumatica tells you Acumatica is willing to take the money for it and the vendor has customers. Neither is a functional fit assessment for the client in front of you, and both are read as one by roughly everyone.

The table below is the version we would put in front of a client, because it separates the four questions people collapse into one. Every row is a question a buyer thinks the badge has answered.

The row that costs the most money is the last one. A connector can be certified, sold on Acumatica’s price list, and still be the wrong choice for a distributor with 40,000 items and 300 orders a day, because certification says nothing about the vendor’s pricing metric or about whether the app’s data model matches how your client prices.

Six checks, none of which take long, and all of which are outside what certification tests. Do them once per vendor and reuse the answers across deals.

The pricing metric check is the one that catches partners out. A connector priced per order, per item synchronized, or per storefront user can be entirely sound engineering and still be uneconomic for a client whose volume triples in year two. Model the vendor’s metric at three times current volume before you put the app in a proposal, because the client will hold you to the number in the proposal.

The framing that works keeps the badge as a positive and moves the conversation to fit, which is where you want it. Something close to: "the badge tells us Acumatica bills for this and holds the vendor to an update schedule, which is genuinely useful because it means it will not fall behind your ERP upgrades. What it does not tell us is whether it handles your pricing, so let us test that specifically."

Then run the test rather than arguing about it. Load one real contract customer and one item that customer has a negotiated price on, into a sandbox, and look at the product page signed in as that customer. That test takes an afternoon and it converts a debate about badges into a screenshot.

Avoid the move of telling a client the badge is meaningless. It is not meaningless, you are both partners of the vendor who issues it, and the client will remember the tone longer than the argument. The badge is a real signal about a narrow thing. Say which narrow thing.