Prophet 21, Vision, and Eclipse are three separate ERPs inside Epicor's distribution lineup, and none of them handles accounts payable the same way. Prophet 21 runs general industrial and specialty distributors. Vision runs automotive, heavy-duty, and appliance parts distributors. Eclipse runs electrical, plumbing, HVAC, and PVF wholesalers. A distributor on one of these three systems is dealing with a specific, named set of AP strengths and gaps, not a generic ERP problem.

The harder case is the distributor group that runs more than one. Grow by acquisition long enough and it's common to end up with Prophet 21 at one division, Vision at an aftermarket arm, and Eclipse at an electrical or plumbing branch, each with its own AP process, its own exception queue, and no shared view of what's owed back on vendor rebates. Epicor's own implementation community treats moving between its distribution products as a full new build, not a migration, so a distributor group doesn't get a shortcut just because all three systems share a vendor.

This piece covers what's native on each system, what Epicor sells as its own fix, where two third-party tools currently stop, and what completing the last step, actually posting into the ERP and reconciling against the bank, looks like across all three.

‍

What Prophet 21, Vision, and Eclipse Are Each Built For

Prophet 21 is Epicor's ERP for general industrial and specialty distribution. It runs businesses selling fasteners, fluid power components, electrical and HVAC supplies, janitorial products, medical supplies, and paper and packaging. Vision is built for automotive, heavy-duty, and appliance parts distributors, including independent jobbers who buy through a central distributor rather than direct from a manufacturer. Eclipse is built for electrical, plumbing, HVAC, and PVF wholesalers, and it's been serving that specific market since 1990, longer than either of the other two has existed under Epicor's ownership.

Prophet 21 and Eclipse get compared often, and there's a real reason for it: a distributor selling electrical supplies or HVAC parts could plausibly run either one, and the two genuinely overlap in that territory. Vision doesn't invite the same comparison. It serves a different industry outright, and a distributor choosing Vision was never choosing between it and Eclipse in the first place.

Eclipse's technical story is worth a second look. It was built on a UniVerse database, and long-running installs still carry that architecture underneath: real-time GL, AP, AR, and credit control on an older foundation. Eclipse has also moved forward, now available as a cloud deployment on Microsoft Azure with REST API connectivity. Both are true, they're just different points on the same product's timeline. Which version a distributor is actually running changes what's available to them for AP automation, and that's worth checking rather than assuming.

‍

‍

AP Automation on Prophet 21

Prophet 21's accounts payable module does two things well natively. It tracks vendor rebates in real time, recording each step from negotiation through receipt and reflecting it in the general ledger and price schedules as it happens, rather than leaving rebate positions to be reconstructed at year end. It also supports early payment discount terms, the kind of 2/10 net 30 arrangement worth roughly 36% annualized if the invoice actually clears in time.

The friction shows up after the invoice posts. Correcting a mistake in Prophet 21 means reversing through the same multi-step process used to record it, not a single undo. For a distributor processing a high volume of invoices, that's recurring labor that scales with volume, the same way keying invoices does.

Prophet 21 offers Epicor ECM as an optional add-on for intelligent data capture, meant to automate invoice entry and cut down on manual paper handling. Getting there through Epicor's official API, rather than through ECM, means licensing a separate API module. Long-running on-premises Prophet 21 sites are frequently told connectivity requires an upgrade or a new license first, a real cost most distributors don't budget for until they're already trying to connect something.

One more piece of context matters for anyone weighing how much to invest in Prophet 21 as it stands today. Epicor's own release schedule sets the final on-premises feature release for Prophet 21 at May 2028, with active support running through June 2029 and sustaining support after that. That's not an urgent deadline, there's still years of runway, but it's a real, dated fact worth knowing before committing to a heavy custom integration project built specifically around today's on-premises version.

‍

AP Automation on Epicor Vision

Vision includes a three-way match feature built into its AP and purchasing workflow, matching invoices against purchase orders and receipts before they post. Vision can also clear a batch of invoices in a single action rather than one at a time, a real capacity advantage for a parts distributor running high invoice volume across multiple locations.

The gap shows up in visibility, not processing. Vision's accounting module sits somewhat apart from day-to-day transaction entry, and pulling a single consolidated view of the accounting picture from inside the system takes more work than the transaction-level tasks do. A controller checking AP status often ends up piecing together a fuller picture rather than getting it from one screen.

Vision serves a broader range of distributors than "automotive aftermarket" alone suggests, covering automotive, heavy-duty, and appliance parts distributors. Customers include XL Parts, 4M Parts Warehouse, Pronto Network, and PWI, and XL Parts has nearly tripled in size since implementing the system.

‍

AP Automation on Epicor Eclipse

Eclipse posts into the general ledger, accounts payable, accounts receivable, and credit control in real time, and the modules stay tightly connected to each other. For a wholesaler managing a large SKU count, that live connection between what's in the warehouse and what's on the books is a genuine advantage.

The gap sits in traceability. Eclipse's audit trail doesn't always make clear which upstream transaction produced a given cost figure, so tracing exactly how a number was built up takes real digging. For a controller verifying a cost before approving payment, or preparing for an audit, that's a real obstacle.

EDI and document imaging, the two modules closest to actual invoice automation, aren't included in Eclipse's core package. They're sold separately, on top of it. That's the same shape as Prophet 21's licensed API: the capability exists, but it's an additional purchase most distributors don't discover until they go looking for it.

‍

‍

Epicor's Own Fix: ECM AP Automation

Epicor sells its own answer to the AP automation gap: ECM AP Automation, built on the Docstar platform the company acquired. It's positioned to capture, index, route, approve, and integrate invoice data with a company's ERP, using intelligent data capture to extract fields, running two- and three-way matching to catch errors, and routing exceptions for review with an audit trail behind it.

Prophet 21 names ECM directly as an optional integration, confirming the two work together. ECM's own integration list is less specific: generic "Epicor," alongside Microsoft Dynamics, Sage, Oracle, SAP, and Infor, without naming Vision or Eclipse anywhere. That's not proof ECM doesn't work with either system, but it's a real gap, and a distributor on Vision or Eclipse evaluating ECM should ask directly which of their specific systems it connects to before assuming coverage.

‍

Third-Party AP Tools for These Systems

ESS Inc built a Prophet 21-specific AP tool called Fusion AI, positioned as a template-free alternative to traditional OCR. It reads invoices the way a person would rather than matching against a fixed template, runs three-way matching against P21's open purchase orders and receipts, and posts validated vouchers directly into Prophet 21 using its own 150-plus endpoint API, built specifically so a distributor doesn't need Epicor's licensed API module to connect. ESS names a handful of customer logos without publishing Prophet 21-specific outcomes for any of them.

BlueCreek Software's Vision360 Enterprise makes a broader, less specific claim: invoice capture, approval routing, two- and three-way matching, and a transfer into "your Epicor ERP system." BlueCreek doesn't say which Epicor systems that covers, so a distributor on Vision or Eclipse would need to confirm directly whether it's built for their system or for Epicor's ERPs generically.

‍

‍

When One Distributor Runs More Than One of These Systems

Distributor groups that grow by acquisition often end up running more than one of these three systems at once. One division runs Prophet 21. An aftermarket parts arm runs Vision. An electrical or plumbing branch runs Eclipse. Each one processes AP on its own, with its own exception queue, and none of them share a line of sight into the others.

That splits a real cost, not just a workflow inconvenience. Prophet 21's rebate tracking only sees Prophet 21's transactions. A group running three systems has three separate, incomplete pictures of what's owed back on vendor rebate programs, and reconstructing a group-wide view at year end is exactly the kind of margin problem that goes unnoticed until it's too late to act on.

Running all three under the Epicor name doesn't create a shortcut either. Moving a company's data or processes from one Epicor distribution product to another isn't treated as a migration inside Epicor's own implementation community. It's built as a full new implementation, because the systems don't share much more with each other than any of them shares with a competing ERP. A distributor group can't lean on "it's all Epicor" as a reason to expect a unified AP process across Prophet 21, Vision, and Eclipse. Nothing about the underlying systems makes that automatic.

This is the exact shape of problem an AP automation layer built to work across systems, rather than inside just one, is meant to solve.

‍

How LayerNext Automates AP on Prophet 21, Vision, and Eclipse

LayerNext reaches whichever of these three systems a distributor runs through the same ERP and Desktop Automation capability used across the rest of the platform. Where a system exposes a usable API, LayerNext uses it. Where it doesn't, or where that access sits behind a separate license the way it does on Prophet 21 and Eclipse, LayerNext's agents operate the system's own interface directly, the same screens and fields a person would use, so getting connected doesn't depend on Epicor granting or pricing that access first.

From there, the process runs the same stages regardless of which system it's connected to. Invoices come in through email, a shared drive, cloud storage, or directly from the system itself. Two- and three-way matching runs against the purchase order and receipt, with vendor-specific rules, the kind of thing that would otherwise mean rebuilding Prophet 21's per-vendor rebate logic or Eclipse's cost-coding habits from scratch, written once in plain English by the finance team rather than filed as an IT ticket. Anything that doesn't match cleanly becomes a named, tagged task instead of a line item buried in someone's inbox. The validated entry posts directly into whichever system it came from. Reconciliation runs against the bank feed as transactions clear, using Plaid for the connection. Every step stays logged for audit.

The same principle already runs on other Epicor distribution systems that don't expose a usable API: an interface a person can operate doesn't need an API to be automated. Extending it to Prophet 21, Vision, and Eclipse is a matter of connecting to each system's own interface, not building a new capability from scratch.

Nothing posts without a human approving it first. Validation gates run before entry, exceptions route to a person with context attached, and every action stays traceable, for the same reason ECM's audit trail matters and Eclipse's cost-traceability gap is a real problem: finance teams are accountable for what enters the ledger, and "the system did it" isn't an answer a controller can give an auditor.

‍

How AP Automation Options Compare Across Prophet 21, Vision, and Eclipse

None of what follows is a choice between an ERP and an AP automation tool. Prophet 21, Vision, and Eclipse stay the system of record either way. What differs is how the invoice actually gets into the ledger and reconciled afterward.

‍

‍

A few questions cut through most vendor claims on any of these options. What happens at the moment of ERP entry, an API, a file import, or the system's own interface operated directly? Which accuracy number is being quoted, field-level, document-level, or the share of invoices that clear with no human touch at all, since only the last one predicts how much work stays on the team? What's the touchless processing rate across the vendor's whole customer base, not their best account, measured against the roughly 49.2% best-in-class benchmark from Ardent Partners' research? And what's the deployment timeline, in writing, for the specific system in question?

A distributor running Prophet 21, Vision, Eclipse, or all three at once can send us your ugliest invoices, the scanned ones, the handwritten ones, the ones that don't match any template, and see exactly what gets matched, what gets flagged, and what would have posted on its own.

‍

FAQ

‍

‍