POS and ERP Integration

Of all the system pairs I have connected across twenty-two years of enterprise work, POS and ERP is the one where a single design decision, whether the store can keep selling when the link goes down, separates the projects that succeed from the ones that generate angry calls at nine on a Saturday morning. A cashier scans an item, takes a card, hands over a receipt. That looks like one clean event, but behind it sit inventory that must decrement, revenue that must post to the ledger, tax that must be accounted for, and loyalty points that must accrue. If the register cannot reach the ERP at that instant, the customer still expects to walk out with their shopping. Connecting the two systems removes the manual re-keying of daily takings and, done properly, keeps stock and finance in step with what is actually selling on the shop floor. This guide walks through how that connection actually works, and it sits in a wider cluster of system-pair integration guides anchored by my enterprise system integrations hub.

The message up front: POS and ERP integration is not primarily a technology problem. The REST calls are easy. The hard part is designing for the moment the network is not there, agreeing which system owns the item and price, and making sure that when a store finally reconnects, every sale it buffered lands in the ERP exactly once. Solve the offline and reconciliation questions first, and the pipes almost build themselves.

1. What POS and ERP each are, and why integrate them

A POS, point of sale system, is where the front of the store lives. It runs the checkout: scanning items, applying promotions, taking tenders (cash, card, gift card, mobile wallet), processing returns and exchanges, printing receipts, and accruing loyalty. Its job is to complete a transaction quickly and reliably at the counter, often across dozens of registers and many stores. Oracle Retail Xstore, NCR, Square, Lightspeed and Shopify POS are typical examples. The POS is optimised for speed and resilience at the till, not for accounting depth.

An ERP, enterprise resource planning system, is where the back office lives. It runs finance, inventory, purchasing, replenishment and reporting. Its job is to execute and account for the business: turn a day of sales into ledger entries, keep stock figures accurate across every location, trigger reordering, and produce the numbers the business runs on. SAP, Oracle, Microsoft Dynamics 365 Business Central and NetSuite are typical examples. The ERP is the system of record for money and stock, built for control and auditability rather than checkout speed.

Organisations integrate the two because a sale at the register is a single business event that begins on the shop floor and must finish in the ledger and the stock file. The tender clears at the POS; the revenue, the tax, the inventory decrement and the daily close belong in the ERP. Without a link, that single event is split across two disconnected systems and stitched back together by hand, usually by someone reconciling till reports against bank statements at the start of the next day. With a link, each sale flows into the ERP as revenue and an inventory movement automatically, and the item and price master, stock levels and promotions flow back to the register so the store always sells at the right price. This pattern is common wherever a physical or counter-based sales operation feeds a central finance and inventory function: retail chains, fashion and grocery, food and beverage and quick-service restaurants, hospitality and hotels, pharmacy, convenience and forecourt, and franchise networks. If you want the underlying concepts before the specifics, my enterprise system integration explained primer covers the fundamentals that every pairing in this cluster relies on.

2. The business problems it solves

The case for integration is easiest to make by listing the specific, daily frustrations it removes. These are the symptoms I hear in almost every discovery session before a POS and ERP project:

• Manual re-keying of takings. Someone reads yesterday's till reports and types the totals into the ERP or a spreadsheet. It is slow, it is error prone, and it means finance is always a day behind the shop floor.
• Wrong stock figures. Sales at the register do not decrement ERP inventory in step, so the stock file says there are twelve on the shelf when there are two. Replenishment orders the wrong quantities and customers are told an item is available when it is not.
• Price and promotion drift. A price changes in the ERP but not on the register, so the till charges yesterday's price, or a promotion that ended keeps applying. Every mismatch is a dispute at the counter and a margin leak.
• Painful reconciliation. Cash, card and gift-card tenders are matched to bank deposits by hand, and any difference triggers a hunt through paper receipts to find where the money went.
• No real-time view. Head office cannot see how stores are trading today. Every sales figure is assembled after the fact, so a fast-selling line is spotted too late to react.
• Tax and closing errors. Tax collected at the till is recomputed by hand for filing, and daily closing totals do not tie back to the ledger, creating audit headaches at period end.
• Human errors. Every manual transfer of a total is a chance to transpose a digit, miss a register or double-count a store. Those errors surface as wrong revenue, wrong stock and finance corrections.

Integration attacks all of these at once by making the data move automatically and by fixing where each field is authoritative. The re-keying disappears, stock moves as the tills sell, prices come from one source, and the daily close ties out to the ledger by design.

3. Integration architecture

At the architectural level, the POS and the ERP almost never talk to each other directly, and in retail there is a second reason beyond the usual coupling concerns: the store network is not reliable, and the tills cannot stop selling when it drops. A direct point-to-point link that assumes the ERP is always reachable will freeze the checkout the moment connectivity blinks. The pattern that survives contact with a real store puts a middleware layer between the two, and pushes an offline-first buffer down to the store itself. Each register or store controller queues transactions locally, keeps trading whether or not the link is up, and forwards to the middleware over a REST API when connectivity returns. The middleware transforms and validates the data and posts it into the ERP. The reverse path, item and price master and stock levels, flows back the same way.

The building blocks worth naming:

• Offline-first store buffer is the block that makes retail different. Each register or store controller holds a local queue of transactions and a local copy of the item, price and promotion data it needs to keep selling. If the link to head office fails, the store trades normally and the queue drains once connectivity returns. No sale is ever blocked on the ERP being reachable.
• REST APIs are the default way modern POS platforms and ERPs exchange data. They are request-driven: the store posts a batch of sales over HTTP, usually with JSON, and pulls the latest master data the same way. Simple, well documented, and adequate for most of the traffic in this pairing.
• Store-and-forward is the pattern behind the buffer. A transaction is written locally and marked unsent, then forwarded to the middleware when a connection exists, then marked sent. It is what turns an unreliable network from a showstopper into a non-event.
• Middleware is the broker in the centre. It owns transformation (mapping POS field names to ERP field names), validation (rejecting bad data before it corrupts the ledger or stock file), routing, de-duplication of replayed transactions, and the retry logic that keeps a temporary ERP outage from losing a day of sales. This is where an integration platform earns its licence fee.
• Message queues and batch both have their place. Sales can flow as a near real time trickle or as micro-batches every few minutes; the full price list and the daily close run on a schedule. Not everything needs to stream, and for slow-moving reference data a scheduled job is simpler and cheaper.

4. Data flow: what moves in each direction

A clean integration is easiest to reason about when you split it by direction and are strict about which system is the source for each object. The two directions carry very different kinds of data.

POS to ERP (the shop floor feeding the back office):

• Sales transactions line by line, so revenue posts and inventory decrements against what was actually sold.
• Returns and exchanges so refunds, credit notes and stock put-backs are accounted for correctly.
• Cash and tenders, the split of each sale across cash, card, gift card and wallet, so the money can be reconciled to deposits.
• Tax collected at the till, captured accurately for the ledger and for filing.
• Daily closing totals per register and per store, the summary that ties the day's trading back to finance.
• Gift card redemptions so the liability on the balance sheet is drawn down as cards are spent.
• Loyalty points earned on each qualifying sale, so the loyalty balance in the ERP or loyalty engine stays current.

ERP to POS (the back office informing the shop floor):

• Item and price master so every register sells the right products at the authoritative price.
• Inventory levels so the till and store staff can see what is actually in stock across locations.
• Promotions so discounts, bundles and campaigns apply consistently and expire on time.
• Gift card balances so a card presented at any store shows its true remaining value.
• Loyalty balances so a member sees and can redeem the points they have actually accumulated.

Notice the pattern. The POS sends what happened at the counter; the ERP sends the reference data the counter needs to sell correctly. Keep that division clear and most of the design decisions make themselves.

5. Data objects exchanged

Putting the concrete objects side by side makes the contract between the two systems explicit. This is the table I sketch on a whiteboard in the first design workshop, because it forces both teams to agree on ownership before anyone writes code.

The left column is what happened at the counter, born at the POS. The right column is the reference and financial truth, born in the ERP. When both teams sign off on this table, arguments about "why did the till charge the wrong price" or "why does the stock figure not match" mostly disappear, because everyone knows which side owns which object.

6. Business process flow

The clearest way to see the integration in action is to follow one item along its whole life and mark which system owns each step. The journey from a priced item on the shelf to a posted ledger entry crosses the POS and ERP boundary at two points: the master data pushed out before the sale, and the sale, close and posting flowing back after it.

The item and price sync is the ERP's territory: the register can only sell correctly if it holds the right products, prices and promotions, and those are pushed out from the ERP before trading starts. The sale at the register, the payment and tender and the inventory decrement at the moment of sale are the POS's world, owned by the store and buffered locally so they happen whether or not the link is up. Then the daily closing gathers the day's trading and crosses back into the ERP as general ledger postings. The single most important discipline in this whole pairing is that the sales buffered at the store during any outage all reach the ledger exactly once, so the close ties out and nothing is lost or double-counted.

7. Real-time versus batch

Not every field needs to move the instant it changes, and treating everything as real time is a common way to make a retail integration expensive and fragile for no benefit. The discipline is to match the timing to how fast the data actually changes and how quickly a stale value would cause harm.

A caution on the daily close: it is tempting to post every sale to the general ledger the instant it happens, in the name of real-time finance. In retail this usually backfires. Sales get voided, returned and corrected through the trading day, and a store that buffered transactions offline will replay them later. If you post each one live, your ledger fills with reversals and your close never ties out cleanly. Stream sales for visibility by all means, but let the ledger posting be a controlled nightly close that reconciles the whole day at once. Your finance team will trust the numbers far more for it.

8. Integration technologies and when each fits

The tooling landscape for POS and ERP integration is broad, and the right choice depends less on fashion than on what the two systems already speak and, crucially, how well each option tolerates an unreliable store network. The options I reach for, and when:

• REST API. The default for anything modern. Current POS platforms and ERPs expose REST endpoints with JSON payloads. Use it for the bulk of your traffic: post a batch of sales, pull the latest price master, check a gift card balance.
• Offline queueing and store-and-forward. The non-negotiable pattern in retail. Each register writes transactions to a local queue and forwards them when a connection exists. Whatever else you choose, this is what keeps the tills selling through a network outage.
• Webhooks. Useful for the ERP to notify the store side of a price or promotion change so it can pull the update, without the store polling constantly. They keep the master-data path prompt and API volumes sane.
• OAuth 2.0. Not a transport but the authorisation standard you will almost certainly use to let each store and the middleware call the POS and ERP APIs securely, with scoped, revocable tokens rather than shared passwords.
• Message queues such as RabbitMQ decouple the store forwarders from the ERP in time. When the ERP is down for maintenance, buffered sales wait in the queue instead of being lost, and processing catches up when it returns.
• Event streaming such as Kafka is the right call for large chains where sales and inventory events must fan out to several downstream systems (analytics, replenishment, e-commerce stock) and you want a durable, replayable log. Overkill for a single small estate, essential at scale.
• SFTP batch. Unglamorous and still everywhere. For the nightly close file, a sales export or a full price-list drop exchanged as a file, SFTP is simple, robust and universally supported.

My rule of thumb: offline queueing at every register without exception, REST plus OAuth 2.0 for the request-driven path, a message queue for reliability between stores and the ERP, and SFTP or nightly batch for the close and the full price list. Reach for Kafka only when the event fan-out across a large estate genuinely justifies it.

9. Security

A POS and ERP link touches payment tenders, prices, tax and customer loyalty data, which makes it a sensitive pipe and puts it squarely in scope for card-industry expectations. The single most important principle here is to keep cardholder data out of the ERP entirely. The essentials:

• No card data in the ERP. The register captures the tender and the payment processor handles the card. What flows to the ERP is the fact of a card payment and its amount, never the primary account number or full card details. Keeping raw card data out of the ERP dramatically narrows what is in scope for the card-industry data security standard and removes a whole class of risk.
• PCI considerations at the boundary. Payment capture, tokenisation and settlement sit inside the payment stack, ideally with the card data tokenised so only a token ever leaves the till. Treat the payment path as a separate, tightly scoped domain and integrate to the ERP only at the reconciliation level of totals and tenders.
• Authentication and authorisation. Every call between a store, the middleware and either system proves who it is with OAuth 2.0 tokens or service credentials, never a shared human login, and is granted the minimum it needs. The store forwarder can post sales but not delete ledger entries; the master-data job can push prices but not read tenders it has no business seeing.
• Encryption. Everything moves over TLS in transit, and sensitive data is protected at rest, including on the store-side buffer where transactions sit while waiting to forward. Never let this traffic run over an unencrypted channel, even inside a store's local network.
• Audit logs and safe failure. Every message, its summary, its source, its outcome and its timestamp are logged, and a rejected or malformed transaction is quarantined, alerted and retried in a controlled way, never silently dropped and never allowed to post half a sale. Good error handling is what stops a transient glitch from becoming a reconciliation incident.

10. Common challenges

The problems that actually derail POS and ERP projects are boringly consistent, and knowing them in advance is most of the battle:

• Offline stores. The network at a store will fail, and the tills must keep selling. If the design does not buffer locally and replay cleanly, an outage becomes lost sales and a broken day. This is the defining challenge of the pairing and the first thing to design for.
• Reconciliation. Cash, card and gift-card tenders must match bank deposits and the ledger to the penny. Duplicated or missing transactions from a messy replay make the day fail to tie out, and finding the gap by hand is painful. De-duplication and idempotent posting are what keep the close clean.
• Multi-store inventory. Stock is spread across many locations and moves constantly. Keeping ERP inventory in step with what every register is selling, without race conditions or double decrements, is genuinely hard at volume and needs careful delta handling.
• Tax rules. Rates and rules vary by product, location and time, and change. If the ERP and the tills disagree on tax, the till charges the wrong amount and the filing is wrong. Tax logic and rates have to be owned in one place and pushed out reliably.
• Price and promotion timing. Every register in the estate must switch to a new price or drop an expired promotion at the same moment. A partial rollout means neighbouring stores charge different prices for the same item, which erodes trust fast.

11. Best practices

The habits that separate an integration people trust from one they route around:

• Design offline-first, always. Assume the network will fail and make the register keep trading regardless. Buffer locally, forward on reconnect, and prove the replay is clean before go-live. Everything else in a retail integration depends on this working.
• Make posting idempotent. Give every transaction a stable unique identifier and ensure that replaying it, which will happen after any outage, posts it exactly once. Idempotent operations are what make the daily close tie out despite retries and buffered replays.
• Define the master system per object. Decide, field by field, which system is authoritative. Item, price, promotion and tax rules are owned by the ERP; the record of what sold and how it was tendered is owned by the POS. Write it down, agree it, and enforce it in the mapping.
• Reconcile daily by design. Build the close so tenders, revenue, tax and inventory all tie back to the ledger automatically, with any exception flagged. Do not leave reconciliation as a manual chore; make it a checked, automated step of the nightly run.
• Log and monitor everything. Track queue depth per store, forward lag, error rate and unreconciled totals, and alert before finance or a store manager notices. An integration that only tells you it broke when the close fails is being watched by the business, not monitored.

The practitioner's insight: the single decision that most determines whether a POS and ERP integration succeeds is committing to offline-first with idempotent posting before any code is written. Assume the store network will fail, let the tills keep selling into a local buffer, and make sure every buffered sale lands in the ledger exactly once when the link returns. Get that right and reconciliation, multi-store stock and the daily close all fall into place. Skip it, and one bad Saturday of network trouble becomes a week of untangling duplicated and missing transactions. This same discipline of designing for failure anchors every guide in the enterprise integrations hub.

12. KPIs: proving it works

An integration is an investment, and like any investment it should be measured, not taken on faith. The metrics I hold a POS and ERP link accountable to:

• Sales sync latency. How long from a transaction at the till to it appearing in the ERP. During normal trading this should be seconds to minutes; after an outage it is how quickly the buffered backlog drains once connectivity returns.
• Reconciliation match rate. The percentage of days where tenders, revenue and tax tie out to the ledger and the bank with no manual intervention. A mature link runs very close to a clean tie-out every day.
• Inventory accuracy. How closely ERP stock matches the physical count across stores. The whole point of selling in step with the stock file is accurate figures, so measure the drift.
• Manual effort saved. The hours of re-keying takings and reconciling by hand eliminated per week. This is the number that pays back the project and the one finance cares about most.
• Return on investment. Effort saved plus errors avoided plus better stock accuracy and faster reporting, set against build and run cost. On POS and ERP the return usually shows up quickly, because the manual close is so visibly wasteful.

13. Industry examples

The same architecture adapts to very different sectors, with the emphasis shifting to match what each business cares about most:

• Retail chains. Many stores and thousands of registers make offline-first buffering and multi-store inventory the whole game, with price and promotion pushes that must hit every till at once.
• Food and beverage. Quick-service and restaurant operations where speed at the counter is everything, tenders are split many ways, and daily closing must tie out across shifts and locations.
• Hospitality and hotels. Outlets, bars and shops post to a central finance system, often with room-charge and gift-card tenders, where accurate tender handling and the nightly close matter more than raw speed.
• Grocery and convenience. Very high transaction volume, tight margins and constant price changes, where inventory accuracy and reliable promotion timing directly protect profit.
• Franchise networks. Independently operated stores rolling up sales, tenders and stock to a central ERP, where consistent data contracts and clean reconciliation across many owners are essential.

These are the same forces that make the neighbouring pairings in this cluster worth reading if your estate is broader than just the shop floor: connecting the online storefront with the ledger in my e-commerce and ERP integration guide, and connecting card processing with the ledger in my payment gateway and ERP integration guide. The architecture rhymes; only the objects and the owning systems change.

14. References

This guide leans on a small set of widely adopted, vendor-neutral standards and patterns rather than any single product's documentation. For the interested reader, the concepts worth reading further on, by name, are:

• REST (Representational State Transfer), the architectural style behind the HTTP and JSON APIs that both modern POS platforms and ERPs expose.
• OAuth 2.0, the authorisation framework for granting scoped, revocable access to those APIs without sharing passwords.
• PCI DSS, the payment card industry data security standard, the reference for keeping cardholder data protected and, in this design, out of the ERP altogether.
• Webhooks, the event-notification pattern that lets one system push changes, such as a price update, to another in near real time instead of being polled.

Each of these is a published, openly documented standard maintained by its respective standards body or community, and the current specifications are the authoritative source rather than any vendor's summary of them.

Final thoughts

Connecting POS and ERP is one of the highest-return integrations a retail or hospitality business can do, precisely because the pain it removes is so visible. The morning re-keying of takings stops, stock moves as the tills sell, prices come from one source, and the daily close ties out to the ledger by design. The benefits, less manual effort, fewer errors, accurate inventory and real-time sight of trading, show up quickly and are easy to measure.

The challenges are just as predictable: stores that must keep selling offline, reconciliation that has to tie out to the penny, inventory spread across many locations, and tax and price rules that must land everywhere at once. None of them is really a technology problem, and all of them yield to the same discipline, design for the network failing and make every buffered sale post exactly once, then build the rest of the pipes to respect it. Looking ahead, the direction of travel is clear: more event-driven, near-real-time sales flows over manual close, more managed cloud integration platforms replacing hand-built middleware, and AI starting to help with the unglamorous work of matching transactions and spotting reconciliation gaps before finance does. The plumbing keeps getting easier. The judgement about offline resilience and clean posting stays exactly as important as it has always been, and that is the part worth getting right.

Related reading: Enterprise system integrations hub, Enterprise system integration explained, E-commerce and ERP integration, Payment gateway and ERP integration.