Every few months a client with a working Acumatica customization asks the same question: "could we sell this?" The honest answer is usually yes, but the path from "a customization project that works for one tenant" to "a listed Marketplace product" is a real program with real gates, not a form you fill in. This is the guide I give people at the start of that conversation.
Two different relationships with Acumatica
Acumatica runs separate partner tracks that people conflate. The VAR/reseller track is about implementing and selling Acumatica itself to end customers. The ISV (Independent Software Vendor) track, run through the Acumatica Development Network (ADN), is about building software on top of Acumatica — a customization package, an integration, an industry add-on — and getting it in front of the reseller channel and end customers through the Acumatica Marketplace. This post is about the ISV track.
Joining the Acumatica Development Network
ADN membership is the entry point: it gives you access to the platform SDK, non-production licensing for development, and the developer documentation and forums. This tier is aimed at getting a product built and technically validated — it is not, by itself, a Marketplace listing.
Certification: the real gate before Marketplace listing
Getting a solution onto the Acumatica Marketplace requires it to pass Acumatica's certification review before listing — this is the step that actually matters and the one worth budgeting real time for. In practice this means Acumatica's enablement team audits your code against platform conventions: proper use of Data Access Classes and DAC extensions rather than direct database access, correct use of the customization project packaging, no core-screen behavior broken by your extension, and adherence to the upgrade-safe patterns the platform expects (extending via PXCacheExtension/PXGraphExtension, not monkey-patching stock code). If you have read this blog's DAC-extension and overfetch posts, that is exactly the bar being checked — a reviewer will reject a solution that queries around the framework instead of through it.
[ ] Extends via PXCacheExtension / PXGraphExtension, not core DAC edits
[ ] No direct SQL / raw database access anywhere in the package
[ ] Customization project installs clean on a fresh instance snapshot
[ ] Uninstall path tested — does the instance return to a clean state?
[ ] No hard dependency on a specific build beyond what you declare
[ ] Multi-tenant / multi-company behavior verified, not just single-tenant
[ ] License/feature gating (if a paid add-on) doesn't break unlicensed users' screensTreating certification as a paperwork step rather than a real code audit is the most common reason a first submission bounces. Budget for at least one round of findings and rework — I have not seen a first-time ISV submission clear on the first pass. Build the checklist above into your own CI before you ever submit.
A higher tier exists above standard certification
Above standard Marketplace certification, Acumatica runs a "Fulfilled by Acumatica" program for a smaller set of hand-selected, more deeply vetted solutions with an ongoing currency commitment (staying tested against new Acumatica releases on a defined cadence). That tier is invitation/selection-based rather than a self-serve next step, and is realistically a multi-year-relationship goal rather than a launch target — I'd treat it as out of scope for a first product and revisit once you have paying customers and a track record.
The commercial side nobody puts in the SDK docs
Getting listed does not create demand. The Marketplace gets browsed mostly by VARs looking for gaps in their own implementation capability, not directly by end customers in large numbers. The ISVs I have seen actually succeed did the unglamorous parts: relationships with a handful of VARs who will actively recommend the add-on to their clients, a demo environment that works without a sales call, and support/SLA commitments written down before the first paying customer, not improvised after.
Wrapping up
The ISV path is real and Acumatica genuinely wants a healthy Marketplace — but "we built a customization that works" and "we have a certifiable, supportable product" are different projects. Build to the upgrade-safe patterns from day one, budget real time for the certification review and its rework cycle, and line up channel relationships before you expect the listing itself to generate leads.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.