ERP add-ons and independent software vendors

An ERP gap can be filled four ways. You can use a feature the ERP publisher already ships (first party) or a product from an independent software vendor that plugs into the ERP (a third-party add-on). You can also have code written for you alone (a custom extension) or connect a separate application through an integration. Each is right somewhere. The cost buyers miss is the seam between the add-on and the ERP, which someone has to support every day and retest at every upgrade.

The four options at a glance

The table compares the four options on support, upgrade risk and best fit.

Option	What it is	Who supports it	Upgrade risk	Best when
Native (first party)	A module or setting the ERP publisher ships and maintains	The publisher, under your maintenance plan	Lowest: tested with each release	The feature exists and fits 80% of the need
Third-party add-on	A packaged product from an independent software vendor (ISV) built for your ERP	The ISV for its product, the publisher for the core	Medium: depends on how fast the ISV certifies each release	A common gap many customers share, solved better than native
Custom extension	Rules, scripts, screens or reports written for you on the ERP extension tools	Whoever wrote it, or you	Medium to high: only as good as its documentation and tests	A process that is genuinely yours and gives you an edge
Separate system, integrated	A standalone application (often SaaS) with its own data, connected by API, EDI or files	The SaaS vendor for its side, someone for the integration	Low for the ERP, but the integration must be retested	The job has its own users, data and pace of change (warehouse, e-commerce, tax, CRM)

Prophet 21 software and Epicor Kinetic both have partner ecosystems of add-on vendors, and both offer extension tools of their own. For how those choices look inside each product, see DynaChange Rules, Designer, a report or an integration? and Epicor Functions, BPMs or customizations?.

How to decide which option fits

Work down the questions and stop at the first yes.

Question	If yes
Does a native feature cover the need once configured, even if the screen is less pleasant?	Use native. Train people on it before buying anything
Is the gap common across companies like yours (tax calculation, EDI, advanced warehouse, freight rating, document capture)?	Look at add-ons and separate systems first, since someone has likely solved it
Does the job have its own users, its own data and a release pace faster than your ERP?	A separate, integrated system usually fits better than an add-on inside the ERP
Is the process how you win business, and nothing on the market does it your way?	A custom extension, documented and tested like a product
None of the above?	Change the process to fit the software, often the cheapest answer

Test "we need it" against the native feature first

Many add-ons are bought to replace a native feature nobody was trained on. Ask a super user or your partner to show the native way before the demo of the add-on. If the native way works with a small process change, the add-on is a cost you carry forever for a training problem.

What to check before you buy an add-on

Upgrade compatibility and release cadence

The first question for any add-on is how fast it supports a new ERP release. Ask for the add-on vendor's record for the last three ERP releases, showing the date each ERP version came out and the date the add-on was certified on it. A vendor that takes six months to catch up holds your whole upgrade hostage.

Check	Good sign	Warning sign
Certification lag	Supported on new ERP releases within weeks, with a public compatibility list	"We'll look at it when a customer upgrades"
How it attaches	Uses the ERP's supported extension points and APIs	Writes directly to ERP database tables, or modifies shipped code
Cloud readiness	Works in the publisher's hosted or SaaS edition, if you may move there	On-premises only, needing server access the cloud edition does not give
Release notes	Published per version, with known issues	None, or only on request

An add-on that writes straight into ERP tables is the biggest single upgrade risk. When the publisher changes a table, the add-on can corrupt data without raising an error.

Who supports the seam

When something breaks between the ERP and the add-on, each vendor can honestly say the problem is on the other side. Settle who you call before you sign, and write it down.

Symptom	First call	Second call	What you need to have ready
Add-on screen errors or wrong result inside the add-on	Add-on vendor	Your implementation partner	Version numbers of both products, steps to reproduce
ERP core error that only happens with the add-on installed	Add-on vendor	ERP publisher support	A test showing the same step works with the add-on disabled
Data wrong in the ERP after the add-on ran	Add-on vendor	Your partner or DBA	Record ids, timestamps, the add-on log
Failure after an ERP update or patch	Add-on vendor (compatibility)	ERP publisher	The update applied, the add-on version, the date it last worked
Integration message rejected between the ERP and a separate system	Whoever built the integration	The SaaS vendor	The message, the error, the queue or log entry

Many ERP publishers will not support problems caused by third-party code, and many add-on vendors will not support a customized ERP. Ask both, in writing, what they do when the other party is involved.

Licensing

These questions expose the full cost of an add-on license over time.

Question	Why it matters
Is it priced per user, per site, per transaction or per company?	Growth, acquisitions and new warehouses can multiply the fee
Does it need extra ERP licenses (API users, named users for a service account)?	Those licenses add to the add-on price
What is the annual maintenance percentage, and is the increase capped?	Uncapped increases compound over the life of the contract
Is the license perpetual or a subscription, and what happens to your data if it lapses?	A lapsed subscription can stop a warehouse

For total cost of ownership across the options, see build, buy or partner.

Data model impact

Ask whether the add-on keeps its data in its own tables, in ERP user-defined fields or in a separate database. Its own tables are cleanest. Heavy use of user-defined fields collides with your own custom fields and other add-ons. Also ask whether reporting sees the add-on data, and whether your data warehouse or reports need to change.

Performance

Add-ons that run on every save (pricing, tax, credit checks) add time to every order line. Ask for the typical added time per transaction and test it in your own test environment with realistic volume. Watch the database during your busiest hour. A second or two per line is invisible in a demo and painful at 2,000 lines a day.

Vendor viability

Small ISVs build excellent products and also get acquired, change direction or close. Ask how many customers run the product on your ERP, how many developers work on it, how long it has been sold and who owns the company. The fourth parties and concentration risk page covers what to do when one small vendor holds a critical process.

Source code and escrow

For a critical add-on from a small vendor, ask for a source code escrow agreement. A neutral escrow agent holds the source and build instructions and releases them to you on named events, such as the vendor going out of business or ending support. Escrow only helps if the deposit is current and buildable, so ask for verified deposits after each release.

For custom extensions written for you, the contract should say you own the code or have a perpetual license to it. It should also say you receive the source and documentation at each delivery.

Not legal advice

Source code ownership, escrow release conditions and liability between vendors are contract terms. Have counsel review add-on agreements, especially for anything that touches pricing, tax or financial posting. See contracts, SLAs and data rights.

Security

An add-on runs with access to your ERP data, often through a service account with broad rights. Ask what account it uses, what it can read and write, whether it sends data outside your network and how the vendor handles its own software supply chain.

NIST SP 800-161 Rev. 1 treats software from suppliers as a supply chain risk to manage across its life. CISA promotes the software bill of materials (SBOM), an inventory of the components inside a product, as a way to know what you are running (both retrieved 2026-09-28). Asking an add-on vendor whether it can provide an SBOM is a quick signal of how seriously it treats this.

A worked example

A mid-sized electrical distributor needs better freight rating at order entry. All figures below are invented for illustration.

Option	One-time cost	Annual cost	Notes
Native freight feature	$0	$0	Covers rate tables but not live carrier rates
Add-on from an ISV	$18,000	$3,600 maintenance (20%)	Certified on the last three ERP releases within six weeks
Custom extension	$40,000 build	$6,000 upkeep	Only the author knows it
Separate shipping system, integrated	$10,000 integration	$12,000 subscription	Also handles labels and tracking

Over five years the add-on costs $18,000 plus 5 × $3,600, or $36,000, and the separate system costs $10,000 plus 5 × $12,000, or $70,000. The add-on wins on cost, but only if its upgrade record holds. The distributor also counted two days of internal testing at each ERP upgrade for the add-on, which the separate system mostly avoids.

Managing add-ons through ERP upgrades

Every add-on and extension is a line item on your upgrade plan. The ERP upgrade checklist covers the full project, and this section covers the add-on part.

Keep an inventory

Record these fields for every add-on and extension.

Field	Example
Name and type	Freight rating add-on, third-party
Vendor and support contact	Supplier A, support portal and account number
Installed version	7.2
How it attaches	Supported API, own tables
Business owner	Shipping manager
Processes it touches	Order entry, shipping, invoicing
Contract dates	Renewal and notice deadline
Last tested on	ERP version and date

Build a compatibility matrix before each upgrade

For each item in the inventory, record the target ERP version, whether the vendor has certified it, the add-on version required, any known issues and the upgrade order (add-on first, ERP first or together). Anything not certified is either a blocker or a documented risk that the project sponsor accepts in writing.

Test the seams between systems

• Run each add-on's main transaction end to end in the upgraded test system. A screen that opens is not proof the data is right.
• Compare outputs with the current system. Price, tax, freight or allocation results should match for the same test orders, or differ for a known reason.
• Test the failure paths. Credit holds, cancellations, returns and partial shipments break add-ons more often than the happy path.
• Check scheduled jobs and integrations. Add-ons often run on a schedule that nobody watches until it stops.
• Time the busy transactions. Compare time per order line before and after.
• Confirm the rollback. Know how to disable the add-on or revert its version if it fails after go-live.

Questions to ask an add-on vendor

1. On which versions of our ERP is the product certified today, and how long did certification take for each of the last three releases?
2. Does it use the ERP publisher's supported APIs or extension points, or does it write to ERP tables directly?
3. Who do we call when the problem sits between your product and the ERP, and what do you do if the publisher points back at you?
4. How many customers run it on our ERP and edition, and can we speak with two of them?
5. What does the full price include: licenses, ERP licenses it needs, maintenance, annual increases?
6. Where does it store data, and how do we export all of it if we leave?
7. What access does its service account need, and does any data leave our environment?
8. Do you offer source code escrow with verified deposits?

Red flags

Treat any of these as a reason to slow down.

• The vendor cannot name its certification dates for past ERP releases.
• The product modifies shipped ERP code or writes to core tables without the publisher's API.
• The vendor says "your partner handles support" and offers no direct support path.
• The product has a single developer, or the company will not say how many people maintain it.
• There is no way to export your data in a usable format.
• The add-on is being bought to avoid learning a native feature.

Start with an inventory

List every add-on, custom extension and integration you run today, with its owner and the ERP version it was last tested on. Most companies find at least one they no longer use and one nobody can support. Retire the first, and put the second on the plan before your next upgrade.