Connecting your shop to your accounts: what nobody tells you first
It sounds like joining two systems and it is five business decisions dressed as technical ones. What to settle before touching anything, and why reconciling the payment gateway is the point that breaks.
· Full-stack development
«Connect the shop to the accounts» sounds like a two-day job. In practice it is where half of a small company's automation projects get stuck, and not because it is technically hard: because underneath it sit five business decisions nobody has taken yet.
This article is for taking them beforehand, which is when they are cheap.
Decision 1: what counts as one entry
Does every order generate its own entry, or do you post a daily or monthly summary?
Order by order gives full traceability and fills the ledger with thousands of lines. A daily summary is clean and forces you down into the shop whenever something does not add up.
For high volumes of small tickets, the summary is usually the sensible one; for a few high-value orders, the detail. What matters is deciding beforehand: changing it later means redoing a whole financial year.
Decision 2: which date rules
The order date, the payment date, the dispatch date or the invoice date. They almost never coincide, and the difference decides which period the VAT falls in.
The recurring case: order on the 30th, payment on the 31st, dispatch on the 2nd of the following month. Which quarter? The answer depends on the applicable tax point rules, not on the shop's preference, and it has to be written into the integration.
Decision 3: how the payment gateway is reconciled
And this is what breaks nearly every project. The gateway does not pay you what you sold: it pays you a batched settlement, late, already net of fees, and sometimes with refunds and holdbacks mixed in.
That is: 4.312,87 € lands in the bank matching no invoice of yours. That entry has to be broken down into sales, fees and refunds, and reconciled against the orders behind it.
If the integration does not handle this, the usual thing happens: income posts automatically and then somebody spends hours every month reconciling the bank by hand. The easy part has been automated and the hard part left behind.
Decision 4: the VAT on each line
Not everything carries the same rate. Shipping may follow the main product, discounts have to be apportioned, and if you sell abroad the rate and even the country of taxation change. The distance-selling threshold and the one-stop shop are in selling online to other EU countries.
An integration that applies a single rate because «nearly everything is standard» produces a small mismatch every day, and a big problem at year end.
Decision 5: what happens with refunds
A refund is not just a negative entry: it may require a credit note, it affects the period's VAT and it can straddle a quarter end. Partial refunds, goodwill payments and commercial credits are all treated differently.
It is the case left until last and the one that redoes the most work.
How it is done properly
- Start with the map on paper. Which field comes from where, with which date, at which rate, and in which account it ends up. One page. If it does not fit, something has not been decided.
- Test with a real closed month. Run a month whose numbers you already know through the integration and compare. The mismatches show up there, not in production.
- Log everything. Every sync, with its result. When something fails to add up — and something will — you need to see what was sent and when.
- Plan for failure. Systems go down and connections time out. The integration has to retry, not duplicate, and tell somebody when it cannot.
- Never duplicate. The most expensive fault: retrying and posting the same order twice. Every operation needs a unique reference that blocks the duplicate.
What you gain when it works
It is not only the typing time. It is that the information is current: you know the real margin per product with fees included, the cash position shows itself, and the quarter's VAT is not a last-week surprise.
And there is a side effect that usually turns out to be the most valuable: building the integration surfaces things that have been wrong for months. Orders never invoiced, fees never posted, refunds charged twice.
If this sounds like you
The integration is custom development. What prevents the mismatch is the data map you draw first: which field comes from where, with which date, and which account it lands in. If for now what you want is to stop typing invoices, the short cut is automatic invoice capture.
And before building anything, it is worth knowing what is worth automating and in what order: the process and AI audit.
We are Mindset & Code: automation, data and development for small businesses. You can see what we do and what it costs.
General guidance. The applicable tax point and invoicing rules depend on the jurisdiction and the type of transaction, and are checked case by case before being fixed into an integration.