Accounting for an online store almost always starts the same way. Sales are few, so the owner runs everything in a single spreadsheet. An order comes in — you type a row. A payment lands — you mark it with a color. You ship the goods — you subtract from stock in your head, or in another file. With ten orders a day this works. Then it becomes fifty, a second person joins, marketplaces get connected — and the spreadsheet stops matching reality. Someone sold what wasn’t in stock. Someone shipped before payment. Someone forgot to reduce the stock, and the site still says “in stock”.
The issue isn’t whether you’re careful. The issue is that manually moving data between the site, the warehouse and the till is work that scales linearly with the number of orders, and the errors in it pile up quietly. This article is about how accounting for an online store works when those three things count themselves: an order deducts stock on its own, a payment settles itself against an order, and documents are generated without retyping.
Where manual accounting actually breaks
Take the typical chain. A customer places an order on the site. Now someone has to: check the item is available; reserve it; wait for payment; match the amount in the bank against the order; pack the shipment; subtract from stock; issue a document; update the status. Eight steps, and each one is a place where a person can get distracted.
The most expensive error here is the mismatch between the site and real stock. The store sells an item that physically isn’t there, because two channels (the site and, say, an in-person sale or a marketplace) draw from the same warehouse but don’t see each other. The customer waits, then gets “sorry, out of stock”. That’s not one lost sale — it’s damaged trust and a negative review.
The second common hole is payments. Money arrives in the bank in a batch, and matching each receipt to a specific order has to be done by eye. Some orders sit as “awaiting payment” even though the money already came. Some get shipped even though no payment did. At month-end it doesn’t reconcile, and you spend an evening checking instead of selling.
What accounting looks like when the order behaves on its own
Systematic accounting for an online store means the order isn’t a row in a table but an object with its own lifecycle, to which stock, payment and documents are attached. When the customer clicks “buy”, the system reserves the item at that same moment. A reservation isn’t a write-off: the item is still in the warehouse, but already unavailable to other orders. That closes the double-sell problem immediately, before anyone gets a chance to make a mistake.
When the order moves to shipping, the reservation turns into an actual write-off. Stock on the site updates not “once a day, when someone gets around to it”, but right then. If you have several sales channels, they all look at one stock figure — and see the same number. The owner stops holding the current warehouse state in their head, because the system holds it more accurately.
The key point: the owner stops being the “synchronizer” between systems. Their attention is freed for the decisions that genuinely need a human — what to buy, what to promote, which customers to handle separately.
Payment that settles without manual reconciliation
The other half of accounting is money. In a well-set-up system, an incoming payment finds its own order and changes its status. The customer paid online — the order is instantly marked paid and can be packed. Paid by bank transfer — the receipt is matched by amount and payment reference, and the order closes without anyone comparing the statement to a list by eye.
This removes two opposite risks at once. You don’t ship the unpaid, because the system won’t let an order move to packing without confirmed payment. And you don’t leave paid orders waiting, because the money is already recognized. At the end of the day, the picture of “how much we’re owed, what’s already paid, what’s ready to ship” isn’t the result of an evening reconciliation — it’s the live state, available at any moment.
Partial payments, prepayments, cash on delivery, refunds — these are part of accounting too, and in a system they don’t break the picture; they’re anticipated states of the order. A refund returns the item to stock on its own. A prepayment reduces the amount due on delivery on its own.
Documents generated from data, not from a keyboard
The third block is documents. The delivery note, the invoice, the act, the carrier waybill. Done manually, they’re retyped: you take the same items, the same amounts, the same details already sitting in the order, and re-key them into a form. That’s not just time — it’s another source of discrepancy, when the document ends up showing something other than what was actually shipped.
When accounting for an online store is built systematically, a document is a derivative of the order. Items, quantities, amounts, customer details are already in the system; the document assembles from them automatically and always matches what was sold. The tracking number from the delivery service flows back into the order, and the customer sees their tracking without a separate email from a manager. The source documents for the accountant come from the same data, rather than being pulled together separately at quarter-end.
This also matters because the bookkeeping and management views converge. You’re not running “one reality for yourself and another for reporting” — the sales, stock and receipts figure is a single one.
Where to start if the store is already running
Most often we’re not handed a blank page — we’re handed a working store with spreadsheets, an order history and the team’s established habits. That’s fine, and even better: live data shows exactly where your process burns time and where it leaks.
The smart first step isn’t “rewrite everything” but to map the real path of an order in your store: where they come from, who touches them, where they get stuck, where stock and payments most often fall out of sync. That map alone usually reveals the two or three spots where automation gives the most effect for the least blood. From there the system grows in stages, without stopping sales.
We at lpf.com.ua have been building systems like this for specific businesses since 2018 and supporting them on our own infrastructure — meaning we don’t disappear after launch. If your accounting for an online store currently rests on manually shuttling data between the site, the warehouse and the till, the place to start is a simple conversation: show us your current order chain, and together we’ll see what can be taken off it. Get in touch — that’s where we’ll begin.