Amazon Epicor Prophet 21 Integration: How It Really Works

Why Does Amazon Epicor Prophet 21 Integration Matter for Distributors?

Most distributors start selling on Amazon with a spreadsheet and a customer service rep. That setup holds up at 20 orders per day. At 150, the gaps between the marketplace and P21 start costing real money in labor, cancellations, account health and margin.

The root issue is that each system holds only part of the truth. Amazon knows the buyer, the price paid, the fees withheld and the return reason. P21 knows available inventory by branch, contract and cost data, and your general ledger. Without a connection between them, people fill the gap, and people make keying mistakes, especially when volume spikes.

Three pain points come up repeatedly when distributors describe their Amazon operations.

What does manual order keying into P21 really cost?

Picture a hypothetical rep who spends about four minutes per order. That covers looking up the item, creating or finding a ship-to, and entering the Amazon order ID as a PO reference. At 100 orders a day, this adds up to more than six hours of labor daily. That is close to one full-time employee retyping data that already exists.

Retyping also creates errors. A transposed SKU or a mistyped ZIP code leads to wrong shipments, missed carrier cutoffs and late ship confirmations. All of these count against your late shipment rate and Order Defect Rate.

How does overselling happen across P21 branches?

P21 tracks quantity on hand, allocated and available by location. Amazon only sees the number you last uploaded. If stock is pushed once daily, a counter sale at one branch and a job order at another can drain units that your listing still shows as in stock.

The fix is to publish a calculated available-to-sell figure rather than raw on-hand, based on:

• Which P21 locations feed Amazon
• Safety stock buffers per item or product group
• Open allocations and backorders
• Scheduled updates every 15 to 30 minutes

Why do pricing and settlements drift out of sync?

Price changes in P21, such as supplier cost updates or new price pages, rarely reach Amazon on time, so margin erodes quietly. Finance faces a second problem: Amazon pays out net of referral fees, FBA fulfillment fees, storage charges, promotions and refunds. Matching each settlement report against P21 invoices by hand can eat up a large share of an accountant's week every cycle. An integration posts fees and payouts to defined GL accounts, so deposits tie out without manual matching.

How Does Amazon Epicor Prophet 21 Integration Work?

At its core, a middleware layer pulls data from Amazon, transforms it into P21 business objects, writes it through supported P21 interfaces and sends status back to Amazon. Nothing touches the P21 SQL database directly, so you stay supported by Epicor and protected through upgrades.

The subsections below walk through the interfaces on each side, the order of events, a field-level mapping and how timing and error handling behave in daily use.

Want to see this running against a P21 test environment? Book a free consultation or demo with Comparatio.

Which Amazon and P21 interfaces are involved?

Amazon exposes everything through the Selling Partner API (SP-API), its REST-based successor to the older MWS services. Orders and Notifications cover new or changed orders. Listings Items and Feeds handle price and quantity. FBA Inventory reports fulfillment center stock, and Reports delivers settlements, returns and reimbursements.

P21 connects through its Middleware REST endpoints. The Transaction API creates sales orders, customers and RMAs exactly as a user would in the UI, while entity endpoints read items, prices and stock. Custom logic, such as tagging Amazon orders with a channel order type, lives in DynaChange business rules, which keeps changes inside Epicor's supported customization framework.

What does the data flow look like?

Think of the connection as a loop with six steps:

1. Amazon sends order notifications to the integration layer in near real time.
2. The layer creates the sales order and ship-to in P21.
3. P21 returns pick, ship, tracking and invoice data.
4. Amazon receives carrier and tracking confirmation.
5. Scheduled jobs push P21 quantities and prices to Amazon.
6. Settlement, fee and return data post to AR, GL and RMA.

Steps one through four happen for every order. Steps five and six run on their own schedules, independent of order activity.

How do Amazon fields map to P21 objects?

Here is a typical starting map. Yours will reflect your order types, locations and GL structure.

• AmazonOrderId: saved as the PO number or web reference on the P21 sales order, so the connector can reject duplicates before they reach order entry.
• Buyer name and ship address: attached to a channel customer, with ship-to records created per buyer or consolidated, depending on how you want AR to look.
• Amazon Business buyers: routed to a dedicated customer and ship-to so tax-exempt certificates are honored.
• SellerSKU and ASIN: translated to a P21 item ID through a cross-reference table that also handles pack-size and unit-of-measure differences.
• ItemPrice and promotions: written as the unit price plus a discount line. The price Amazon charged overrides the P21 price on import.
• ItemTax: posted to a tax line or an exempt jurisdiction. Under marketplace facilitator laws Amazon remits tax in most states, so the mapping avoids charging it twice.
• Referral and FBA fees: pulled from the settlement report and posted to GL fee accounts through a journal entry or AP.
• FBA inventory: held in a dedicated P21 location and reconciled against Amazon's FBA Inventory API.
• FBM shipments: the pick ticket, carrier and tracking number flow back to Amazon through SP-API.
• Returns and refunds: created as an RMA plus credit memo, with Amazon reason codes deciding whether units are restocked or scrapped.

How often does data sync, and what happens when a record fails?

Orders arrive via notifications, with a 5 to 15 minute polling fallback. Shipment confirmations go out within minutes of P21 ship confirmation, inventory at quarter-hour to half-hour intervals, pricing hourly or nightly, and settlements whenever Amazon releases a report.

A failed record, such as an unmapped SKU, lands in an exception queue instead of disappearing. Transient API errors retry with exponential backoff. Persistent ones trigger an alert naming the order and cause, so staff fix the data once and resubmit. That queue-and-retry pattern also applies to trading partner documents, as our piece on how MCP enables AI-powered EDI integration explains.

What Does Epicor Prophet 21 Integration Look Like Beyond Amazon?

Amazon is rarely a distributor's only sales channel. Most P21 shops also run a B2B web store, exchange EDI documents with large customers, and ship through a WMS, 3PL or carrier platform. When each of those connections is built as a separate one-off project, you end up maintaining duplicate item mappings and inventory rules that contradict each other.

A better approach keeps P21 as the system of record and routes every channel through a single integration layer. That layer holds shared item cross-references, one available-to-sell calculation and consistent order tagging. Adding the next channel then becomes a configuration task instead of a rebuild.

Related pages: P21 eCommerce integration, P21 EDI integration and P21 multichannel integration.

How does Amazon fit alongside eCommerce, EDI and WMS?

A typical distributor stack includes:

• B2B eCommerce: customer-specific contract and ship-to pricing pulled from P21 in real time
• Amazon Seller Central and Amazon Business: FBM orders filled from branch stock, with FBA replenishment tracked as transfers
• Amazon Vendor Central: purchase orders usually exchanged as ANSI X12 850, 855, 856 and 810 documents
• EDI trading partners: big-box retailers and national accounts
• WMS or 3PL: pick, pack and ship confirmations written back to P21
• Carriers: rates and tracking numbers recorded in P21 and passed to each channel

Because every channel draws from one inventory pool, allocated by channel rules, a spike in Amazon orders cannot quietly oversell stock promised to an EDI account. The same partner-mapping discipline applies on other Epicor platforms. Our guide to EDI integration for Epicor Eclipse shows how those document flows are set up.

Which P21 versions and hosting models are supported?

Connections built on the P21 Middleware and Transaction API perform best on current releases, where those REST services are mature. Older versions are assessed during discovery, and some may need an upgrade or a narrower scope.

On-premises P21: the connector reaches your middleware server over a secured link, and your IT team keeps control of network and firewall rules.

Epicor Cloud (hosted P21): We read Epicor-hosted P21 through read-only database logins over the encrypted connection Epicor requires; in the moves we have handled, Epicor provided them on request. Orders go into P21 through its own import files or the P21 Transaction API. Obtaining credentials and coordinating environments with Epicor adds lead time, so build that into the project schedule. Confirming the hosting model early, before any field mapping starts, keeps a Comparatio rollout plan realistic.

Which Integration Option Fits Your P21 Environment?

Most distributors weigh four paths when planning an amazon epicor prophet 21 integration: Epicor's native commerce tooling, a generic iPaaS (integration platform as a service), a custom API build by internal or contract developers, or a managed integration service. Any of them can work. The better fit depends on your order volume, how much IT capacity you have in house, and how much P21-specific logic the connection has to respect. That logic includes ship-to handling, contract pricing, RMAs and multi-branch inventory.

If you already exchange documents with big-box retailers, much of that discipline carries over. Our guide on how to set up EDI covers the partner testing and mapping habits that apply equally to marketplace work.

Before you compare vendors, download the Amazon-to-P21 field-mapping checklist and integration readiness guide. It lists every data decision you will face, whichever option you pick.

How do the four options compare?

Here is how the four paths stack up on upfront cost, speed, Amazon depth, P21 depth, upkeep and room to grow.

Native Epicor commerce tooling. Licensing runs moderate to high, and timelines vary because the Amazon piece is often bundled into a larger storefront rollout. P21 depth is excellent, since the tooling comes from the same vendor, and Epicor handles maintenance. The weak spot is marketplace coverage: FBA, fee posting and settlement handling are limited. Expansion to new channels generally stays inside the Epicor ecosystem.

Generic iPaaS. License fees start low, but configuration effort is high. Expect 8 to 16 weeks to reach production with skilled staff. Amazon support comes from templates that need customizing for FBA and settlements, and the P21 connectors are generic rather than built around order entry, ship-tos or RMAs. You own every flow and every API update after launch. Adding channels is straightforward if you have people available to build them.

Custom API build. Development cost is high, and timelines of three to six months or longer are common. Marketplace and ERP depth are whatever your developers deliver, which depends heavily on their P21 experience. Your team owns all upkeep, and each new channel tends to mean another build from scratch.

Managed integration services (Comparatio). Pricing is moderate with a fixed scope, and many projects reach production in roughly two to three months, depending on scope. Amazon workflows for FBA, fees and settlements are pre-built, while mapping is P21-specific and informed by DynaChange experience. Monitoring and maintenance are handled for you, and additional channels plug into one shared layer.

When does each option make sense?

• Native tooling: A strong fit when your main goal is a P21-driven B2B web store and Amazon sits in second place.
• Generic iPaaS: Works for teams that employ an integration developer who can own flows and keep up with SP-API changes for years, not months.
• Custom build: Suits unusual requirements no platform handles. Budget for ongoing upkeep, because Amazon revises SP-API endpoints and seller policies regularly.
• Managed services: Makes sense for lean IT teams that want one accountable partner covering marketplace expertise, P21 knowledge, monitoring and upgrades. Comparatio's service is designed around that arrangement.

A practical test helps here: ask who will fix a failed settlement import at 7 a.m. on a Monday. The honest answer usually points to the right option.

What Do Amazon Epicor Prophet 21 Integration Services From Comparatio Include?

Comparatio's services cover the full lifecycle: scoping, data preparation, build, testing, cutover and ongoing monitoring. The aim is a connection your team does not have to babysit, with clear ownership when something needs attention. Below is the process we follow, what influences cost, and what support looks like after launch. Questions now? Talk to a P21 integration specialist.

What are the implementation phases and timelines?

1. Discovery (1 to 2 weeks): document channels, order types, locations, tax, GL and return policies.
2. Data cleanup (1 to 3 weeks): validate item IDs, UOMs and ASIN cross-references, and resolve duplicate SKUs.
3. Mapping (about a week or two): sign off on field mapping, using the baseline shown earlier as a starting point.
4. Build and configuration (2 to 4 weeks): connectors, business rules and any DynaChange changes.
5. Testing (1 to 2 weeks): end-to-end runs in a P21 test environment, including FBA, returns and settlements.
6. Go-live (1 week): phased cutover, often starting with FBM orders.
7. Hypercare (2 to 4 weeks): daily exception review and tuning.

Most projects go live in 6 to 12 weeks. Data cleanup is the phase most likely to stretch, since messy cross-references surface during testing if they are not fixed first.

What drives the cost of an integration project?

The biggest factors:

• Number of Amazon accounts and marketplaces (Seller Central, Vendor Central, Amazon Business)
• FBA on top of FBM
• SKU count and the condition of ASIN-to-item cross-references
• Settlement and fee posting to the GL
• Returns processed as RMAs and credit memos
• DynaChange customizations and your P21 hosting model
• Other channels, such as EDI trading partners, added to the same layer (our guide to EDI integration for distributors covers that side)

How are support and monitoring handled after go-live?

Once hypercare ends, the connection moves to managed support: automated monitoring of queues and API health, alerts on failed orders or stalled syncs, and a named contact who knows P21. Maintenance includes Amazon SP-API changes and regression testing for P21 upgrades, so a new report format or release does not turn into an internal fire drill.

What results can distributors realistically expect?

Picture a hypothetical electrical distributor handling 120 Amazon orders a day across FBM and FBA from three P21 branches. After going live, it could reasonably aim to:

• Recover several hours of daily order-entry labor
• Nearly eliminate keying errors, since orders arrive as structured data
• Reduce oversell cancellations by publishing available-to-sell quantities every 15 minutes
• Cut settlement reconciliation from a full day to under an hour per cycle

Actual outcomes depend on data quality and volume, which discovery will quantify. Request a scoped quote or timeline estimate for your Epicor Prophet 21 integration services project, and you will receive a written scope within a few business days of the discovery call.

Frequently Asked Questions About P21 and Amazon Integration

These are the questions ERP administrators and marketplace managers raise most often during scoping.

How often do orders, inventory and pricing sync?

Orders move in near real time, typically landing in P21 within a few minutes of checkout. Inventory quantities usually push to Amazon every 15 to 30 minutes. Pricing updates run hourly or overnight, depending on how often your price pages change. Each interval is configurable, as long as it stays inside Amazon's API allowances.

How is FBA inventory reconciled in P21?

FBA stock lives in its own P21 location. When you ship to an Amazon fulfillment center, that movement is recorded as a transfer, and each FBA sale relieves quantity from the dedicated location. The connector then compares FBA Inventory API data and Amazon's reimbursement reports against P21 balances. Any lost, damaged or stranded units get flagged so your team can file a claim or correct the record.

Can P21 contract pricing be used on Amazon Business?

Partly. Amazon Business supports business-only prices and quantity discount tiers, and both can be generated from P21 price pages. True customer-specific contract pricing, where one account gets its own negotiated rate, works better on your own B2B storefront.

How are Amazon SP-API rate limits handled?

The Selling Partner API assigns each operation a usage plan enforced through token-bucket throttling. To stay within those limits, listing changes are batched into feeds and requests wait in a queue. When Amazon returns a throttling response, the connector backs off automatically. Queued work retries until it succeeds, so nothing is dropped.

What happens when we upgrade P21?

Upgrades rarely cause breakage, because the connection relies on Epicor's supported Middleware and Transaction API instead of writing directly to the database. Before you promote an upgrade to production, Comparatio tests the integration in your upgraded test environment to confirm orders, inventory and pricing still flow correctly.

How long does implementation take, and what does it cost?

Most projects finish in 6 to 12 weeks. Cost depends on the drivers outlined in the previous section. After discovery, you receive a fixed written scope, so the budget is settled before any build work begins.

Frequently Asked Questions