POS and ERP integration: why the boundary matters and how to get it right
How retail POS should connect to Dynamics 365 Business Central or SAP Business One: what to sync, what to post, why a hub helps and how to reconcile.
Two systems, two jobs
A point-of-sale system is built for speed at the counter: scan, tender, print, next customer. An ERP such as Microsoft Dynamics 365 Business Central or SAP Business One is built for control in the back office: ledgers, inventory valuation, purchasing, payables and receivables, tax and reporting. Neither is good at the other's job.
Retailers need both, and they need them to agree. The integration between the two decides whether finance closes the month in days or in weeks, whether stock values match the shelves and whether an auditor trusts the numbers.
What flows in each direction
| Direction | What moves | Why it matters |
|---|---|---|
| ERP or head office to POS | Items, barcodes, prices, customers, vendors, warehouses, tax codes | Stores sell what finance and merchandising have approved |
| POS to ERP | Sales, refunds, payments, end-of-day batches, goods receipts, stock movements | The ledger and inventory reflect what happened in stores |
| Both ways | Stock levels, transfers, purchase orders and receipts | Replenishment and valuation stay in step |
Keep these directions distinct in your mind and in the design. Master data is pulled to stores. Transactions are pushed from stores. Mixing them causes conflicts.
Why not connect tills straight to the ERP
It is tempting to have every till call the ERP directly. It rarely works well at scale.
- Speed and uptime. A sale should never wait for the ERP or for a distant network.
- Security. Giving every till ERP credentials multiplies the risk.
- Load. Hundreds of tills hitting the ERP can slow it down for finance users.
- Change. Every ERP upgrade or customisation would need changes across all tills.
A better pattern is a hub. Branch tills sync to a head-office integration layer. That layer validates and stages documents, then posts them to the ERP using controlled workers. The tills never hold ERP credentials and never call the ERP directly.
Idempotent, auditable posting
Networks fail, and messages get retried. Posting must be safe to repeat.
- Idempotent. Each transaction carries a unique key so the same sale cannot post twice.
- Staged. Documents land in a staging area where they can be validated and, if needed, fixed before they hit the ledger.
- Auditable. Each posting records what was sent, when and with what result, so anyone can trace a ledger entry back to the till and forward again.
- Retry-aware. Failures are queued and retried, with alerts if they persist.
What to post, and how much detail
You have a choice about the grain of posting.
- Detailed posting creates a document for each sale. It gives a precise audit trail but creates large volumes in the ERP.
- Summarised posting creates daily or per-till batches. It is lighter on the ERP but needs good reporting to trace back.
Many retailers use a hybrid: detailed data in the POS and hub, summarised ledger entries in the ERP, and a clear link between the two for audit. Whatever you choose, decide it early with finance and your auditors, because changing it later is painful.
The retail documents that matter
- Sales and refunds. Revenue, tax, discounts and cost of sales.
- Payments and settlements. Cash, card, mobile money and bank, matched to providers and the bank.
- Goods receipts and purchase orders. Stock coming in, matched to supplier invoices through a three-way match.
- Stock transfers and adjustments. Movement between branches and controlled write-offs.
- End-of-day batches. The daily financial close from each store.
- Production or assembly. Where retailers make food or kit products, consumption and output.
Dynamics 365 Business Central and SAP Business One
The same retail event becomes different documents in different ERPs. In Business Central, sales are pushed as cash sales through the hub and orders can be pulled back, with purchase documents staged the same way. In SAP Business One, a sale becomes the A/R invoice, the incoming payment and the inventory issue. A good integration hides these differences from the till and handles the mapping for each ERP in the hub. That is why mapping workbooks and a shared reconciliation approach matter more than any single connector.
Reconcile, then reconcile again
Even with perfect posting, you need proof. A regular reconciliation between POS and ERP shows that totals agree by store, day and tender type, and explains any difference. A month-end report that compares POS sales with ERP postings is a practical control and a strong answer for auditors. Treat unreconciled differences as incidents, not as noise.
Plan for the unglamorous parts
- Time zones and cut-off. A sale just after midnight belongs to the right day.
- Rounding and tax. Tax calculations must agree between systems.
- Master data quality. Duplicate items and customers cause failures downstream.
- Customisations. Heavily customised ERPs need careful mapping and testing.
- Outages. If the ERP is down, the hub should queue work. See offline-first retail systems.
Questions to ask a vendor
- Do tills ever call the ERP directly?
- How do you prevent duplicate postings?
- Can I see the staging area and fix a failed document?
- How do you reconcile POS and ERP, and how often?
- What does a refund look like in each ERP?
- Which master data comes from the ERP and which is maintained centrally?
- How do ERP upgrades affect the integration?