How to Integrate E-Commerce with Inventory and Accounting

Name an owner for every number first. In most small businesses the inventory or ERP system owns real stock, the storefront owns the order, and the accounting package owns the ledger, customer subledger and tax entries. Most integration bugs begin when two systems both believe they control the same number, such as available stock, and quietly overwrite each other on every sync.

Write the ownership list down. It forces decisions that would otherwise be made silently, and differently, by each developer who builds a connector, usually in the middle of a deadline.

A sale should reduce available stock. A cancellation before dispatch should put it back, and a return after delivery should restock the item or write it off if damaged, and raise a credit note. Integrations usually get the plain sale right and mishandle the return and cancellation paths, which are tested far less often, since demos show only the happy order.

Consider a footwear retailer whose customer return updates warehouse stock but never creates the matching credit note in accounting, so stock and books drift apart silently. Nobody notices until month-end reconciliation turns up a gap, and by then dozens of returns have to be traced back by hand.

One SKU, one meaning. The storefront, the inventory system and the accounting package must all use the same code for a product, or the integration ends up maintaining a fragile crosswalk table. Settle this before launch.

Tax fields need the same discipline. Tax rate, tax code and place of supply should flow from product setup to the invoice, never be retyped at the accounting stage where typos hide. A regular reconciliation catches sync drift early. Compare order totals in the storefront with what landed in accounting each week, and investigate every difference while the orders are still fresh in memory.

Decide deliberately between near-instant sync through webhooks and a short polling interval, based on how quickly stock moves and how costly one oversold unit would be. Faster is not automatically better. Webhooks mean more infrastructure to monitor and replay, so the real risk of overselling should justify the extra work before anyone builds them.

Plan for failure whatever the method. A webhook can go missing, an API call can time out, and a retry can create a duplicate order unless every write is idempotent. Add a heartbeat alert for silence. Overselling controls such as a held-back buffer, or an automatic hold when a stock check fails, cost less to design in than to retrofit after an oversold order. Schedule a nightly resync as well.

Test beyond the clean successful order. Write scenarios for a return on a partially refunded order, a cancellation after the accounting entry exists, two orders racing for the last unit, and a failing sync.

“It worked in the demo” proves little. Keep the scenario list in writing, run it against real product data, and rerun it whenever a connector, tax setting or payment provider changes.