Avoiding Accounting Mistakes: The 5 Most Common in Online Retail

Most accounting mistakes in online retail are not arithmetic mistakes. They are gaps — things that did not happen, and therefore do not announce themselves. A wrong number eventually gets corrected by someone; a missing document simply stays missing until a tax audit asks for it.

The five below turn up in almost every set of e-commerce books the first time they are examined. All five are avoidable, and none of them calls for more care — they call for a different structure.

1. Archiving that does not meet GoBD

The classic: invoices sit as PDFs in a folder or inside the shop system, and nobody has checked whether that satisfies the legal requirement.

Section 146 of the German Fiscal Code (AO) requires entries to be made individually, completely, correctly, in a timely manner and in order. The GoBD rules turn that into five requirements that any archive has to be measured against:

Requirement	What it means in practice
Traceability	Every transaction is backed by a document — no exceptions
Timeliness	Cash daily, non-cash income within ten days at the latest
Accuracy	The entry reflects what actually happened and is coded correctly
Immutability	Recorded data is never overwritten; corrections are reversals with a reference
Order	Systematic, understandable to a third party, no duplicate invoice numbers

How to spot it: if an invoice that has already been posted can still be edited in your system without leaving a trace, immutability is not satisfied. This is the most common silent breach, because a shop system never asks the question.

What helps: an archive that is write-protected and keeps changes as versions, plus a real month-end close with a lock. Without the lock, the books stay editable indefinitely — and therefore contestable.

2. Tax codes assigned to the wrong thing

In cross-border distance selling the rate follows the delivery country, not the product. As soon as OSS, intra-Community supplies or third countries are involved, you get combinations that blanket coding does not cover.

The cases that typically go wrong:

• German VAT on a sale to France, because the delivery address was never evaluated
• Reverse charge without a validated VAT ID — the liability then stays with the seller, not the buyer. The VAT number validator answers that in seconds
• 7% instead of 19% on mixed baskets, because the rate applies per line item, not per order
• OSS sales inside the regular return, which makes both filings wrong at once

What it costs: these usually surface only in an audit — which means with interest, over several years. The fundamentals on clean separation are in the post on OSS and IOSS; the arithmetic can be checked in the VAT calculator.

3. Payment, document and order are not connected

Payments arrive through Stripe or PayPal, documents live in the shop or at Amazon, and nothing links the two. The result is two kinds of orphan: unposted documents and unexplained receipts.

The root of it is that a payout never corresponds to an order. It is a balance of sales, fees, refunds and withheld reserves. Book it as one line and revenue is understated while fees were never recorded at all — how to unpick that per provider is described in the post on payment provider accounting.

How to spot it: the simplest check is a count. Orders in the shop against documents in the books, month by month. If they differ, something is missing — regardless of whether the totals happen to agree.

4. Amazon stock movements nobody noticed

If you use FBA with the Europe-wide programmes, you are not only selling from Germany. Amazon relocates inventory on its own initiative into warehouses in Poland, the Czech Republic, France or Spain — without any sale having taken place.

For VAT purposes these are intra-Community transfers: a supply the seller makes to themselves, which can trigger a registration obligation in the destination country. Importantly, the OSS scheme does not cover transfers. Relying on it leaves a gap that the OSS report itself will never show.

How to spot it: the Amazon report contains movements with no matching order. If you have never seen one, you have probably never looked. The post on Amazon FBA and multi-marketplace accounting goes through the affected programmes in detail.

5. Manual exports through spreadsheets

The fifth is not a single mistake but a source of them: exporting from Amazon, Shopify, PayPal and the invoicing tool separately, then merging the files by hand.

The problem is not the effort — it is that every manual intermediate step is a place where something can be lost without producing an error message. A column sorted independently of its neighbours, a number formatted as text, a row cut off while copying: the export completes, the file looks right, and the mistake reappears months later as a difference nobody can trace.

The most common DATEV import failures, incidentally, are known and testable — the EXTF error checklist and the DATEV export validator catch them before the file reaches the firm.

The five share one cause

Four of the five arise in the same place: where data moves from one system into another and nobody checks that it arrived complete. That is why more care helps so little — the gap does not open while you work, it opens between two pieces of work.

To find out where it opens in your own business, the e-commerce accounting score gives you an assessment in about three minutes. To put a number on what the manual route costs, the accounting cost calculator gives you a ballpark.

KudTax is built around exactly those handovers: documents and transactions are collected rather than exported, payments are matched to orders, tax rate and tax country are derived from the delivery address, and stock movements are recognised as what they are. Anything no rule covers is not guessed — it is put in front of you as a proposal.

The honest summary is still this: none of the five is a software problem. They are process problems, and software helps only because it forces the process.