# ERP add-ons and independent software vendors

> When to use a native ERP feature, a third-party add-on, a custom extension or a connected system, what to check before buying and how to handle upgrades.

Source: https://docs.lumina-erp.com/first-and-third-parties/erp-add-ons-and-isvs/

**In short.** Use what the ERP publisher ships first, buy an add-on when a specialist has already solved a common gap, build a custom extension only for what makes you different and connect a separate system when the job has its own users and data. Every add-on you keep is a seam that someone has to support and test at every upgrade, so weigh support, upgrade record and exit alongside features.

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?](/prophet-21/choosing-dynachange-or-integration/) and [Epicor Functions, BPMs or customizations?](/epicor-kinetic/functions-bpms-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 |

:::tip[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](/first-and-third-parties/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](/first-and-third-parties/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.

:::caution[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](/first-and-third-parties/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](/erp-projects/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.

## Sources

- [NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations](https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final)
- [Software Bill of Materials (SBOM) (CISA)](https://www.cisa.gov/sbom)
- [NIST Cybersecurity Framework 2.0](https://www.nist.gov/cyberframework)

---

Epicor, Prophet 21, P21 and DynaChange are trademarks or registered trademarks of Epicor Software Corporation registered in the United States and other countries. Kinetic is a trademark of Epicor Software Corporation. Lumina ERP is an independent consultancy and is not affiliated with, sponsored by or endorsed by Epicor.