Two online stores, three ways to pay, and one ledger that had to balance

BS Babes runs two consumer brands out of one commercial kitchen in Durban: Brigid's Catering, which does catering, events and frozen meals, and B's Babes, which does frozen meals for babies and families. One company, one Xero organisation, two separate WooCommerce stores, and customers paying three different ways: bank transfer, card through Yoco, and card through Zapper at the counter.

Each of those routes arrived in the accounts differently, and none of them arrived on its own. Bank transfer orders had to be invoiced by hand, which meant the ones nobody got around to invoicing were the ones nobody chased. Card takings landed in the bank as a single settled lump days after the sale, with the fee already deducted, so the sale, the fee and the money arriving were three facts that had to be put back together manually.

The underlying problem was not effort. It was that the ledger could not answer, on any given day, whether what the card machines said had been taken matched what Xero said had been earned.

A single service, running on Cloudflare Workers, that talks to both stores, both card providers and Xero on a schedule. It holds its own state, so it always knows what it has already posted.

Bank transfer orders become invoices in Xero automatically, with each line matched to the right inventory item and priced at what the customer actually paid rather than what the catalogue says. Every line carries a tracking category for the brand that sold it, so one ledger still produces a profit and loss per brand. Invoices are raised but not sent: the bookkeeper decides when a customer gets an email.

Card money is handled differently, and deliberately so. A card sale is not an invoice, it is money already taken, so each sale posts into a control account in Xero for that provider at the gross amount. When the provider settles, the fee posts as its own expense and the net amount transfers from the control account to the bank account. That way the fee is visible as a cost of trading rather than buried in a smaller deposit, and the control account carries the money that has been taken but not yet paid over.

Anything that writes to a ledger has to be safe to run twice. Every posting is recorded the moment the provider confirms it, and a settlement that fails halfway through will retry only the leg that did not complete. That behaviour is covered by tests that deliberately break the connection partway and then check the ledger, because this is exactly the failure nobody notices until the accounts are wrong.

Where the system is not sure, it stops. An order whose lines do not add up to the order total to the cent is flagged rather than posted. An order with no way to identify the customer is set aside rather than guessed at. The exceptions go on a list a person works through.

A separate read only job re-reads the raw takings from Yoco and Zapper and checks them against what is sitting in Xero. On the last full audit it reconciled 791 Yoco orders and 112 payouts against the control account with no difference, and the Zapper account the same way. It reports duplicates and possible double counts as its own category, because a reconciliation that only ever agrees with itself is not telling you anything.

That audit earned its place before go live. It found that a batch of cancelled and unpaid orders would have been recognised as revenue, which was corrected and then covered by a test so it cannot come back. One genuine discrepancy of R235 is still open on purpose. It is a judgement call for the bookkeeper, and the system is not designed to make it go away quietly.

The daily work of turning orders and card takings into accounting entries is no longer done by a person. Bank transfer orders raise their own invoices through the day, and the card providers are pulled in each morning before anyone opens the books.

The more useful change is that the question can now be answered. What the card machines took and what the ledger says was earned are checked against each other on demand, from the providers' own data, and the answer is either exact or it is a short list of things to look at.