Posting POS Data to ERP (Dynamics, Business Central, SAP, NetSuite, Odoo)

What an ERP actually wants from a POS

An ERP does not care about every button press at the till. It cares about the accounting consequences of the day's selling activity: revenue by account, taxes by jurisdiction, tenders that must match the bank, cost of goods sold, and inventory movements. A clean POS-to-ERP integration translates POS events into those five categories and nothing more. Everything else (loyalty redemptions, voids, drawer counts, employee meals) is either a discount, a tender, or a stock movement under the hood.

Daily summary vs transaction-level posting

There are two viable patterns for posting POS data, and they answer different questions. Choosing one is the first architectural decision in any integration.

• Daily summary (Z-report) posting: one journal per branch per day. Lines aggregate sales by tax rate, by revenue account, and by tender. Pros: small ERP footprint, fast close, easy reconciliation. Cons: drill-down to a specific receipt requires going back to the POS.
• Transaction-level posting: every receipt becomes a sales document (invoice or sales order) in the ERP. Pros: full audit trail inside the ERP, per-customer history when loyalty IDs are captured. Cons: high document volume, slower month-end, ERP licensing costs scale with transaction count.
• Hybrid: transaction-level for B2B invoices and refunds, daily summary for cash-and-carry retail tickets. This is the most common shape in mid-market deployments.

The five posting buckets

Regardless of ERP or posting cadence, every POS-to-ERP integration moves the same five buckets. Map them once, reuse forever.

1. 1.Revenue

   Net sales split by department, category, or item-group, posted to one or more revenue accounts. Discounts are either contra-revenue (preferred for retail) or expense (rare). Service charge, delivery fee, and packaging fee usually post to separate revenue accounts.

2. 2.Tax

   Sales tax / VAT / GST broken down by rate and jurisdiction. A 15% bucket, a 0% bucket, an exempt bucket. For e-invoicing regimes (ZATCA Phase 2 in Saudi Arabia, similar regimes in Egypt, India GST, Italy SDI), the tax line is derived from cleared invoices, not from the POS estimate.

3. 3.Tenders

   Cash, card (by scheme if the acquirer settles separately), wallet, gift card, voucher, on-account. Each tender posts to its own clearing account so the bank reconciliation can match settlement deposits.

4. 4.COGS

   Cost of goods sold, posted either at the moment of sale (perpetual) or as a period adjustment (periodic). Recipe-aware POS systems can post component-level COGS for prepared items rather than a single SKU cost.

5. 5.Stock movement

   Reductions in finished-goods or ingredient inventory. For F&B, this is the recipe explosion: one burger sold equals one bun, one patty, two pickles consumed.

Per-ERP shapes

Each ERP exposes different objects for the same five buckets. The integration's job is to pick the right object so the finance team's existing reports keep working.

• Microsoft Dynamics 365 Finance & Operations: retail channel functionality natively expects POS statements. Posting goes through the Retail Statement, which generates Sales Orders, Invoices, and Inventory transactions in one batch. Custom POS systems mimic this by posting a General Journal plus an Inventory Journal, or by calling the Retail Channel data API.
• Dynamics 365 Business Central: smaller-footprint sibling. Common shape is a Sales Invoice per day per branch using a generic 'Cash Sale' customer, plus an Item Journal for stock. Tenders post via Cash Receipt Journal lines against bank accounts. Per-receipt posting uses the standard Sales Invoice with the loyalty customer or a one-off card.
• SAP (S/4HANA and Business One): SAP expects either DSD (Direct Store Delivery) / POS DM (Data Management) feeds for enterprise retail, or a simpler A/R Invoice plus Goods Issue for SAP Business One. For S/4, POS Inbound IDocs (WPUUMS, WPUTAB, WPUFIB) remain the canonical structure for sales, tender, and means-of-payment.
• Oracle NetSuite: post a Cash Sale record per transaction or a daily Journal Entry with Inventory Adjustment for stock. NetSuite's SuiteScript and REST APIs are commonly used; subsidiary, location, and class dimensions must be set on every line or the saved searches break.
• Odoo: the native Point of Sale module posts to the accounting module on session close, producing one journal entry per session per payment method. Third-party POS systems typically emulate this by creating an account.move record and stock.move records via the XML-RPC or web API.

Tender breakdowns and the clearing problem

Cash is easy: it moves from drawer to safe to bank, and the bank deposit slip matches the Z-report cash line. Card is where reconciliation breaks. The card acquirer settles net of fees, often on a T+1 or T+2 cycle, sometimes batching multiple days. If the ERP posts gross card sales to the bank account directly, the bank reconciliation will never tie. The correct pattern is a card-clearing account per acquirer or per scheme: POS posts gross sales to clearing on day T, the acquirer settlement file posts net deposit to bank on day T+1 or T+2, and the fees post to an expense account. The clearing account should run flat over a month.

Tax buckets and e-invoicing

Multi-rate environments need explicit bucket mapping. A single 'VAT Payable' GL account is fine for the trial balance, but the tax return needs the underlying split. Most ERPs do this with a Tax Code on each line; the POS must tag every item with the correct tax code or pass the rate explicitly. In e-invoicing regimes, the POS does not finalise tax: it issues an invoice, the clearance platform validates and assigns a UUID and QR, and the cleared invoice is the legal source of truth that posts to the ERP. POSMena handles ZATCA Phase 2 clearance and reports the cleared invoice payload to the integration layer; equivalent flows exist for Egypt ETA, India GST IRP, and Italy SDI.

COGS and stock movement reconciliation

Two patterns dominate. Posting COGS at sale (perpetual) gives accurate gross margin per day but requires the POS to know cost. Posting COGS as a period adjustment (periodic) is simpler but defers margin visibility to month-end inventory count. Recipe-aware POS systems (POSMena, for example, explodes a menu item into ingredient consumption at the moment of sale) enable perpetual COGS even for F&B, where the sold SKU is not the stocked SKU. For multi-branch operators, branch-level costing matters: the same chicken breast may have a different landed cost in two cities, and consolidating both into a single average will hide the margin problem in the more expensive branch. Channel-aware costing (dine-in vs delivery aggregator) further separates aggregator commission from raw food cost so the P&L by channel is honest.

Reconciliation checklist

A POS-to-ERP integration is only as good as the daily reconciliation it enables. Run these checks before signing off on the integration in production.

• Z-report total = sum of ERP journal lines for that branch and date, gross.
• Cash declared at till = cash line posted to safe/bank clearing in ERP.
• Card gross by acquirer in POS = card clearing debits in ERP; card clearing flat at month-end after settlement postings.
• Tax per rate per branch in POS = tax accrual movement in ERP, and = cleared-invoice archive for e-invoicing jurisdictions.
• Items sold in POS = stock-out quantity in ERP (or recipe-exploded ingredient stock-out for prepared items).
• COGS posted = unit cost at branch level multiplied by quantity sold, with channel-aware overrides where applicable.
• Refunds and voids post with negative sign to the same revenue and tax buckets, not to a separate 'returns' account that bypasses VAT.