Accounting system and website out of sync: why stock figures drift and how to fix it

An integration between an accounting system and a website almost never breaks loudly. It breaks partially: most of the data flows fine while some share of items lives its own life. The logs stay clean, the exchange reports success, and the drift only becomes visible when a customer has paid for something you do not have.

Below are the four most common reasons this happens, and a way to test your own exchange without taking it apart.

Why the exchange cannot see every change

Most integrations work on the principle of "give me what changed since last time". That is fast and economical. But the change set usually excludes archived and deleted items — they simply are not in the response.

The result is a one-sided link: additions and updates arrive, disappearance does not. An item is withdrawn from sale in the accounting system and stays on the site. Over six months a noticeable number of these accumulate, and every one is a potential order for something that does not exist.

The fix is not rebuilding the exchange but adding regular full reconciliation to it: once a day, compare the lists in full and bring the flags back in line.

Two: stock is counted by different rules

In an accounting system, stock is not a single number. There is the physical quantity in the warehouse, the amount reserved against orders, and the amount available to sell. The site needs the available figure, but what gets exported is often the physical one, because it is easier to obtain.

So the site shows ten units, eight of which are already reserved for other people's orders. Formally the data is correct; practically, the site is selling somebody else's goods.

• Establish which figure actually goes to the site and compare it with what your staff see in the accounting system.
• Check the warehouses separately: exports often include all of them, transit and damaged stock included.
• If an item sells both in store and online, decide what portion of stock the site is allowed to show at all.

Three: the exchange fails silently

Large catalogues are exported in batches. If one batch does not arrive — the connection dropped, a timeout expired, the server returned an error — many implementations simply move on to the next one. The operation is reported as successful even though part of the data was lost.

A particular variant: the exchange hits a limit on request size. A batch larger than allowed gets cut at the network level, and that looks less like an application error than a random disconnect. These are only caught by measurement: send batches of different sizes and find the threshold at which the connection breaks.

The signature of this problem: the discrepancies move around. Today one set of items is missing, tomorrow another, with no shared category or supplier. A systematic error does not behave that way.

Four: the two systems match products by different keys

The site and the accounting system have to match products on the same attribute. If the exchange is keyed on the part number, and part numbers were edited or entered with stray spaces and mixed case, some items stop being found. The exchange then creates a duplicate instead of updating the existing product page.

Duplicates are usually the first visible symptom: identical products with different stock figures appear in the catalogue. The fix is to key on an immutable internal identifier rather than on whatever is convenient for humans.

How to test your own exchange

The check takes an evening and requires no access to the integration code.

• Count active items in the accounting system and product pages on the site. The numbers should match; a gap above one per cent already warrants investigation.
• Take five products and compare stock by hand: in the accounting system, on the site, and physically in the warehouse.
• Archive one item in the accounting system and watch what happens on the site within twenty-four hours.
• Look for duplicate names in the site catalogue — their presence points to a problem with the matching key.
• Ask your contractor what happens when part of an export fails to arrive. Test the answer "the exchange reports an error" in practice.

The conclusion is straightforward: an exchange without regular reconciliation always starts lying eventually. Not because it is badly written, but because incremental transfer structurally cannot see some events. Reconciliation costs less than one order you had to cancel.