Should Every Store Sale Post to Your ERP? POS Posting and End-of-Day Reconciliation

It’s the fourth working day of the month. The controller has the card processor’s settlement report, the POS end-of-day report from 22 stores, and the ERP’s sales ledger. The three totals don’t match. Two stores were offline for part of a Saturday. One posted twice. A web order returned at a counter shows up as a refund in one system and nowhere in the other. Someone starts calling store managers. 

“Finance has one view, sales has another, eCommerce has a third.” Most teams end up here for the same reason: nobody decided how store sales should post to the ERP. The connector did whatever it did by default, and finance inherited the result. In the worst cases, “We’re re-entering the same order in three systems.” In others, the opposite: every receipt posts automatically, and the ERP is drowning in POS transactions nobody can review. 

How you post POS sales to the ERP is a finance design decision, not a technical default. Posting every sale as a full ERP order is sometimes right and often wrong. This guide covers the four ways to post, the questions to settle with finance before you pick one, how tenders, returns, and stock should flow, what a daily reconciliation should check, and how it typically works in NetSuite, Business Central, and SAP Business One. 

There are four common ways to post POS sales to an ERP. Each lands something different in the ledger, and each puts the reconciliation effort in a different place. 

Option	What lands in the ERP	Pros	Cons	Best for
1. Each sale as an order or invoice	One sales order or invoice per receipt, with lines, customer, and payment	Full line-level detail and customer history in the ERP; every receipt traceable	Highest ERP volume; order workflows built for shipping get applied to counter sales	Low-volume stores, account customers, serialized or warrantied goods
2. Each sale as a cash sale	One paid-in-full sale per receipt, no fulfillment step	Line detail without the order-to-ship workflow; stock and revenue post together	Still one ERP record per receipt; refunds and exchanges need care	Moderate volume where finance wants receipt-level detail
3. Daily summary per store	One journal entry or summary invoice per store per day, split by revenue, tax, discount, and tender	Low ERP volume; easy to tie to the end-of-day report and bank deposits	No customer or line history in the ERP; stock needs its own posting	High volume, mostly anonymous retail sales
4. Hybrid	Summaries for anonymous sales; individual documents for account, special-order, and serialized sales	Detail only where someone needs it	Two flows to build, test, and reconcile	Stores that mix walk-in retail with trade or special orders

The volume difference is not small. Twenty stores averaging 500 receipts a day is 10,000 ERP documents a day under options 1 or 2, and 20 under option 3. That is the difference between an ERP that finance can review and one that only an integration can read. 

High-volume operators commonly post daily summaries by location and keep receipt detail in the POS, where it is searchable and already reported. Lower-volume businesses, and businesses where most sales belong to a known account, more often post each sale. Neither is wrong. What goes wrong is not choosing: posting every receipt as a sales order by default, then discovering at month end that finance can’t find anything in 300,000 documents. 

Can you change from per-sale posting to a daily summary later? Yes, but treat it as a project. Reports, revenue analysis, and anything built on ERP customer history will change, so agree the cutover date with finance and run both in parallel for at least one close. 

The posting design should come out of a conversation with your controller, not out of a connector’s default settings. Settle these before anyone maps a field: 

1. What does finance need to close the month? Usually revenue, tax, discounts, and tenders by store and day, tied to bank deposits. If that is all, a summary is enough. 
2. When do you need line-level detail in the ERP? Customer purchase history, serial numbers, warranties, rebates tied to items, or account customers who get a statement. Each of these is a reason to post that sale individually. If none apply, line detail can stay in the POS. 
3. Which sales belong to a known account? Charge-to-account and trade sales need an invoice against the customer so AR can collect. Anonymous retail sales don’t. 
4. Where will people look up a receipt? If store staff and customer service use the POS for receipt lookups, the ERP doesn’t need to hold every one. 
5. Do you need real-time or batch posting? Batch at end of day is simpler to reconcile. Real-time posting gives fresher reports but more records to check. 
6. What posting date and period rules apply? Decide whether a sale posts on the business date or the sync date, and what happens when a store syncs into a period finance has already locked. 
7. What audit trail is required? Agree what the integration must log: data mapping used, source receipt numbers, audit logs and error tracking for every failed post. 

This is design work, not accounting advice. Your finance team and auditors own the answers; the integration just has to honor them consistently. 

Revenue is the easy half. Tender reconciliation is where store postings usually break, because every tender type settles differently and on a different day. 

Tender	Where it should post	What to reconcile it against
Cash	A cash-in-transit or store cash account, by store	The counted drawer and the bank deposit; differences go to cash over and short
Card	A payments clearing account, by processor	The processor’s payout to the bank, net of merchant fees, often one to three days later
Gift card (sold)	Gift card liability, not revenue	The gift card system’s outstanding balance
Gift card (redeemed)	Reduces gift card liability	The same balance, decremented at redemption
Store credit	Store credit liability	The store credit balance per customer
Charge to account	Accounts receivable, against the customer	The customer’s statement and credit limit

Three rules keep this clean: 

• Use a clearing account for card tenders. Post the gross card total to clearing on the sale date, then clear it when the payout lands, booking merchant fees as an expense. That is how POS payouts reconcile to the bank without guesswork. 
• Treat gift cards and store credit as liabilities until redeemed. That is the usual treatment; confirm it with your finance team. Posting them as sales overstates revenue and leaves nothing to reconcile the balance against. 
• Post charge-to-account sales individually, even in a summary design. At a distributor’s branch counter, an account customer’s sale has to become an invoice on their account under their net terms, or AR has nothing to collect. This is the most common reason a summary design becomes a hybrid. 

If payment terms and credit limits don’t carry across systems, the counter can sell past a customer’s limit. Why Payment Terms Sync Still Creates Financial Risk covers that gap in detail. 

A return is not just a negative sale. It reverses revenue and tax, refunds a tender, and usually puts stock back, and each of those can land in a different system. Decide how each type posts: 

• Same-store return of a store sale. In a per-sale design, post a credit memo (or return document) linked to the original sale. In a summary design, returns net into that day’s store summary as their own line, so returns stay visible rather than hidden inside lower sales. 
• Exchange. Post it as a return plus a new sale, not as an edit to the original. Edits to posted documents are where integrations quietly break; see Why Order Edits Quietly Break Your ERP-eCommerce Integration. 
• Online order returned in store. This is the hard one. The original sale lives in the web order flow, but the refund happens at the register. Decide which system records the refund: usually the system that holds the original order, so the credit memo links to it. The POS captures the return and the refunded tender; the integration posts the credit against the web order, and the store’s drawer or card total reflects the refund. 
• Refund to a different tender. A card sale refunded as store credit moves value from the card clearing account to store credit liability. Make sure that move is posted, not just the refund. 

Whatever you decide, the return has to carry a reference to the original sale and the store that took it back. Without both, finance can match neither the refund nor the stock. Why Returns Are the Most Dangerous Part of Your ERP-eCommerce Integration goes deeper on the failure modes. 

A daily summary journal posts money. It does not move stock. If you summarize sales, inventory needs its own posting, or the ERP’s on-hand by location will drift further every day. 

The usual pattern is a daily stock posting per store: one inventory adjustment or shipment document per location, with a line per item and the quantity sold net of returns. It posts alongside the financial summary, uses the same business date, and relieves cost of goods sold at the same time. 

Three things to watch: 

• Timing. If stock posts only at end of day, the ERP’s store on-hand is wrong until then. That matters if the ERP feeds availability to the website. If it does, either post stock more often than the money, or let the POS publish availability directly. 
• Late posts. When a store syncs late, the stock movement must post on the business date it happened, not the day it arrived, or period-end inventory will be wrong. 
• Items the ERP doesn’t track. Gift cards, services, and fees need to be excluded from the stock posting and mapped to revenue or liability accounts instead. 

For how store stock should be owned in the first place, see Piece 3, . 

Good POS end of day reconciliation with an ERP happens daily, per store, and mostly by exception. Nobody should be tying out 22 stores by hand on the fourth working day. 

Why doesn’t the cash drawer match the ERP? 

When the drawer, the Z-report (the POS end-of-day report), and the ERP disagree, the cause is almost always one of these: 

• Timing. The ERP posted on the sync date, the drawer was counted on the business date. 
• Tender mapping. A tender type, such as a new gift card program or a split payment, is mapped to the wrong account or not mapped at all. 
• Missing or duplicate transactions. A store was offline and some sales never arrived, or arrived twice. 
• Returns and payouts. Cash refunds or petty-cash payouts left the drawer but never posted. 
• Real differences. Miscounts and errors, which belong in cash over and short. 

The first four are integration problems. Only the last one is a store problem. 

The daily checklist 

These checks should run automatically after each store’s postings, with results in an exceptions queue that finance and store operations can both see: 

• Transaction count: receipts in the POS equal receipts (or summary lines) posted to the ERP, per store and business date. 
• Sales totals: net sales, tax, and discounts in the ERP equal the Z-report. 
• Tender totals: each tender type equals the Z-report, and card totals match the processor’s batch. 
• Cash: counted cash equals expected cash; the difference posts to cash over and short with a reason. 
• Stock: the daily stock posting exists for every store that sold something. 
• Liabilities: gift card and store credit movements match their systems’ balances. 
• Failures: every failed or held posting has an owner and a reason in the audit log. 
• Settlement (next day): card payouts landed in the bank and cleared the clearing account, net of merchant fees. 

The exceptions queue is the key. Each entry should show the store, business date, source receipt numbers, the amount, the rule that failed, and who owns it. If the queue is empty, the day is closed. Month-end close with store sales then becomes a sum of closed days, not a reconstruction. 

By ERP 

Each ERP has its own document types for store sales. At a high level: 

ERP	Per-sale posting	Summary posting	Watch for
NetSuite	Cash Sale for a completed, paid store sale; Sales Order when the sale needs fulfillment later	Journal entry or summary Cash Sale per location and day	Using Sales Orders for counter sales adds fulfillment and billing steps nobody needs
Business Central	Sales invoice (or sales order) per sale	Journal or summary invoice per store and day	Unposted invoices don’t move inventory until they post
SAP Business One	A/R invoice with a payment per sale	Journal entry or summary A/R invoice per store and day	Volume of A/R documents; payment means per tender

NetSuite: Cash Sale or Sales Order? 

A Cash Sale records a sale that is paid in full at the time of purchase, with no separate fulfillment step. A Sales Order records a commitment to fulfill later, then gets fulfilled and billed. For a completed counter sale, Cash Sale is the natural fit, and NetSuite’s own Shopify connector posts completed POS orders as cash sales by default. A POS sale that needs shipping, such as a ship-from-store or special order, belongs on a Sales Order. For store pickup of a web order, the Sales Order already exists; the store fulfills it rather than creating a new sale. 

High-volume operators on NetSuite commonly move from a Cash Sale per receipt to a summary per location and day, with a separate daily inventory posting. 

Business Central 

With Microsoft’s Shopify connector, Shopify POS orders import like any other Shopify order. A POS order that is already fulfilled becomes a sales invoice, and because an unposted sales invoice doesn’t reduce inventory, Microsoft recommends posting those invoices promptly. Some businesses set up a separate Shopify shop record in BC just for POS orders, so POS sales can use their own defaults. Depending on how Shopify POS is used, a BC Device license may also be needed. BC customers with LS Central post store sales through its own end-of-day statement process instead.  

If you are still on Navision (NAV), the same choice applies when you move to BC: decide the posting design before the migration rather than carrying over whatever NAV did. 

SAP Business One 

B1 doesn’t need every receipt. Per-sale designs typically create an A/R invoice with an incoming payment for each receipt; summary designs post one journal entry or summary A/R invoice per store per day, with incoming payments split by tender. Item-level summaries still need a goods issue or delivery to move stock.  

For the integration side, see Shopify and SAP Business One integration, Shopify NetSuite integration, and Microsoft’s Shopify Connector for Business Central.  

A store that loses its connection for four hours keeps selling. When it reconnects, it sends four hours of sales at once, often with retries if the first attempt times out. Without protection, some of those sales post twice. 

The fix is idempotency: every sale carries a unique key, usually store, register, and receipt number, and the integration refuses to post a key it has already posted. The ERP document stores that key, so a retry finds the existing record instead of creating a new one. Summary designs need the same rule one level up: one summary per store per business date, rebuilt rather than added to if late sales arrive. 

When offline sales arrive, they should post on their business date, not the sync date, and the daily checks should rerun for that date. If the date falls in a locked period, the posting goes to the exceptions queue for finance to decide, never silently into the current period. 

Questions to ask a POS or integration vendor: How are receipts keyed? What happens on a retry? Can a summary be rebuilt? Where do failed posts go, and who sees them? Batch vs real-time posting also matters here: real-time feeds are more exposed to retries during outages, while batch postings are easier to rebuild. Why ‘Real-Time’ Sync Isn’t Always Real-Time explains why.

There is no single right way to post POS sales to the ERP. There is a design that fits your volume, your account customers, and what finance needs to close, and it should be chosen on purpose. Settle the questions with finance, map every tender, decide how returns and stock move, and run the daily checks. Then month end is a sum of days that are already closed. 

Next step: score your stores’ posting and reconciliation setup with our multi-store architecture scorecard , or take the ERP-eCommerce alignment audit to find where your systems disagree today. 

More in this series 

• Pillar: Multi-store ERP integration
• Piece 2: Real-time inventory by location and store pickup
• Piece 3: Who Owns Stock and Price? Multi-Store Integration Architecture
• Piece 5: NetSuite POS retirement and your options
• Beyond the Sync: the integration truths no one tells you