Most distributors end up running three core systems, whether they planned to or not: an ERP for operations (orders, stock, purchasing and delivery), an accounting system for the general ledger and financial statements, and a B2B e-commerce storefront where customers order online. How those three share data decides whether you can trust the numbers in any of them.
What each layer owns
| System | Owns | Needs from the others |
|---|---|---|
| ERP | Customers, items, prices, stock, orders, purchasing, deliveries | Online orders from the storefront; payment status from accounting |
| Accounting | General ledger, receivable and payable balances, bank, financial statements | Every invoice, credit, receipt and supplier bill from the ERP |
| Storefront | The online catalogue, carts and customer logins | Each customer's price, stock available to sell, order history |
The rule that keeps a stack sane: every piece of data has one home. A customer's price lives in one place. Stock lives in one place. Everything else reads it from there and never keeps its own copy to edit.
The best-of-breed trap
The appealing answer is to pick the best tool for each layer and connect them. It can work. In practice, each connection brings costs that do not show up on the quotes:
- Every integration needs an owner. Someone has to notice when it stops, and fix it.
- Versions drift. One vendor changes a field, and the connector breaks until someone updates it.
- Timing gaps. An invoice created in the ERP this morning is not in accounting until the next sync, so the AR aging a collector is working from is out of date.
- Prices disagree. The storefront shows one price and the invoice another, because two systems calculate it in two ways.
- Finger-pointing. When the numbers do not match, each vendor says the problem is in the other system.
The consolidated alternative
An ERP that includes accounting and a storefront avoids most of that. With one database, an invoice is in the ledger the moment it exists, and the storefront price comes from the same calculation as the rep's order. Fewer vendors also means one upgrade path and one number to call.
The trade-off is that you depend on one vendor for more of the business. That makes its API and its data export more important, not less. Our piece on API-first ERP explains what to check.
When to keep systems separate
- Your accountants are settled. If your accounting team or outside accountant is deeply set up in a separate package, the cost of moving is real. It can wait until the ERP change is finished.
- Specialised accounting needs. Consolidating several legal entities, or other complex group reporting, may need more than an ERP's built-in accounting.
- A storefront you have invested in. If you have built a heavily customised online store, moving it may cost more than you gain, at least at first.
Integration patterns when you split
| Pattern | How it works | Use it for |
|---|---|---|
| Event-driven (webhooks) | The source system calls the other when something happens | Data that must move quickly, where the vendor supports it |
| Scheduled API sync | An integration asks for changes every few minutes or every hour | Most order, customer and item data |
| Nightly batch | A file or bulk export once a day | Supplier records, summary postings, reporting copies |
| Manual import | A person exports a spreadsheet and imports it elsewhere | One-off loads only, never a daily process |
Whatever the pattern, build three things into it: a log of what moved, an alert when a run fails, and a way to re-send a record without creating a duplicate. Customer-facing data, such as balances and open invoices, deserves the fastest pattern you can support, because a customer who is told the wrong balance calls you about it.
Questions for a vendor that says it does all three
- Do sales, purchasing and inventory post to the general ledger as they happen, or in a batch?
- Does the storefront use the same price calculation as an order entered by a rep?
- Does an online order arrive as the same kind of order the warehouse already picks?
- Can the accounting side handle what you will need in a few years: more warehouses, more bank accounts, more entities?
- If we keep one layer outside, what can the API read and write?
For most distributors, fewer systems wins. The savings show up as fewer sync errors, fewer vendors to manage and fewer arguments about which number is right. If a move is on the cards, read switching ERP systems without losing a beat first.
How APFoodz covers the three layers
APFoodz runs operations, accounting and a B2B ordering storefront in one system. For tools you keep outside it, there is an open API.