The Warehouse Records Your German VAT Adviser Actually Needs: A Practical Guide for E-commerce Sellers

Your German VAT registration has gone through, and the stock is in a German warehouse or on a truck heading there. A few weeks later your adviser emails asking for the period's stock movements, the returns, anything written off and a closing balance.

This is usually the moment a seller notices that the warehouse and the adviser describe the same pallets in different terms. The warehouse system records SKUs, bin locations and barcode scans. Your adviser works in periods and totals. Translating one into the other falls to you, and it is much easier to set up before the first request than to reconstruct after it.

What follows covers the warehouse side: which records a fulfilment provider can produce, how to ask for them and what to check before anything goes to your adviser. German VAT rules themselves stay with your adviser.

Who is responsible for which record

Your adviser decides which records they need, how often and in what layout, so the first step is simply to ask. Your part is access: setting up logins or export rights, requesting the data and checking it against your own figures before it is passed on. The fulfilment provider supplies operational data from its warehouse management system and, where it holds them, documents such as delivery notes and proof of dispatch.

The provider can't tell you what your adviser wants, and its reports only cover part of the picture. Amazon holds the marketplace data. Tracking comes from the carrier, and order data lives in your shop system or ERP.

None of this is tax advice. Where the article mentions something your adviser may ask for, confirm it with them first.

Inventory movements: the stock ledger

The core record is the movement history, often called the stock ledger. It has one line for every event that changed a quantity: receipts, moves between locations, dispatches, transfers to Amazon, adjustments and write-offs. A usable line carries the date, SKU, quantity, direction, a reference (shipment, order or return number) and the from and to locations.

For VAT, the lines that matter most cross a border: moving your own stock from another EU country into a German warehouse, or out of one, has to be reported even with no sale, so every line needs both countries.

A stock balance shows what was on the shelf at one moment and nothing about how it got there. Say 40 units of a SKU disappear between March and April, or the count drops on a day with no orders. The balance confirms the gap exists. Only the movement history shows where the units went, and without it someone ends up rebuilding the answer from order exports and memory.

These are bookkeeping rules, not VAT rules. A foreign company that is only registered for VAT in Germany normally keeps its books under its home country's rules. German bookkeeping rules lean on the same kind of record. A business that has to take an annual inventory under § 240 HGB (the German Commercial Code) can count on or close to the balance sheet date (R 5.3 EStR, the German income tax guidelines, allows ten days either side), move the count into a window running from three months before to two months after that date (§ 241(3) HGB), or use a permanent inventory under § 241(2) HGB. The permanent route depends on a stock ledger that records every receipt and issue by date, type and quantity, with at least one physical check per financial year. Whether these rules apply to your business, and which method fits, is for your adviser to say.

Your adviser may also want the position at the end of a past period, so the balance has to be reproducible for any date, not only today. Two questions for the provider cover most of this. Can the movement history be filtered by SKU, date range and movement type? And can stock-on-hand be shown as of a date you pick?

Inbound records

For each delivery, the receiving record should show the expected quantity, the quantity received, the receipt date, the reference numbers and any discrepancy. Damaged and quarantined units belong there as well, with the reason and the date each one was released, reworked or removed.

The record is only worth something if it traces back to your own paperwork. Whatever reference you put on a shipment, whether a purchase order number, an advance shipping notice (ASN) or a supplier shipment ID, should be the one printed on the warehouse receipt. If you call a delivery PO-2291 and the warehouse books it under an internal number with no link to yours, matching the two later means opening every shipment by hand.

Agree the reference format before the first truck arrives and check that the receiving report shows your reference next to the warehouse's own. Short deliveries, overages and wrong SKUs should each get a separate entry with a date and a status, so the quantity booked in is the quantity that was actually counted.

Outbound records

Each dispatch line should carry the date, SKU, quantity, sales channel, destination, customer type (D2C or B2B), carrier and tracking number. Keep the channels apart. Amazon.de, your own store, eBay and B2B orders usually arrive through different integrations, and once a report merges them it is hard to split them again.

Replenishment transfers to Amazon go in the same report with their own references. Amazon issues inbound plan and shipment identifiers in Seller Central (shipment IDs start with “FBA”), and a single replenishment can be split into several shipments going to different fulfilment centres. Record each shipment ID next to the quantity sent. That ID is what ties the warehouse's dispatch line to the units Amazon later reports as received.

Returns and removals

Returns are where a lot of the noise comes from. A University of Bamberg study estimated that German shoppers sent back almost 530 million parcels in 2021, containing around 1.3 billion items, which is close to one parcel in four. At that rate, the returns line is often where a reconciliation stops adding up.

Every returned or removed unit needs a recorded outcome (restocked, reworked, disposed of or forwarded) and a link to where it came from: the original order for a customer return, the removal order for an Amazon removal. The outcome date matters just as much. A unit that comes back in one month and is restocked in the next appears in two different monthly balances.

An Amazon removal runs on a removal order with its own ID, and the seller chooses the method, such as return to an address or disposal. Amazon documents that some automatic removals are reported separately from standard removal orders, so check which Seller Central view covers which units. When removed stock reaches the warehouse, it should be booked against the removal order number and then given an outcome like any other return. Disposals need a record of their own.

Stock reconciliation

The arithmetic is simple: opening balance, plus receipts, minus dispatches, plus or minus adjustments, equals closing balance. The hard part is that three systems hold a version of it: the warehouse's records, your own system and the marketplace inventory view.

On the Amazon side the main source is the Inventory Ledger report in Seller Central. It replaced six older FBA inventory reports, including Inventory Reconciliation and Inventory Adjustments, in January 2023. The summary view gives a starting balance, receipts, customer shipments, returns, adjustments, removals and an ending balance per SKU and disposition (sellable, customer damaged, carrier damaged and so on). The detailed view lists each event with its fulfilment centre and country.

Expect the three sets of figures to differ. Units in transit, stock in quarantine and a return booked in one system a day before the other all produce gaps, and finding and explaining them is part of the routine. Timing also matters for another reason. Since January 2025, Amazon's European stores give sellers 60 days to file a manual claim for units lost or damaged in a fulfilment centre, down from 18 months, and removal claims run on similarly short windows. A difference you only spot at year end may be too old to claim.

Decide in advance who compares the views and how often, who investigates a difference and how it is written up, who signs off an adjustment and with what evidence, and where a difference goes when nobody can explain it. Monthly is a sensible minimum given the claim windows.

Stock counts feed into all of this. A variance line should show the SKU, the expected and counted quantities, the count date and the adjustment that followed. How often to count is an operational agreement between you and the provider, though if German inventory rules apply to you, the one-count-a-year minimum above sets a floor. Ask your adviser whether they need a particular cycle.

How long the data has to last

German retention periods are long. Under § 147 AO (the German Fiscal Code), books, records, inventories and annual accounts are kept for ten years. Booking vouchers such as invoices were cut from ten to eight years from 1 January 2025 by the Fourth Bureaucracy Relief Act (BEG IV), and business correspondence stays at six. Which category a given warehouse export falls into is your adviser's call.

Set that against what the systems actually keep. Amazon's Inventory Ledger holds 18 months of history. A fulfilment contract is usually much shorter than ten years, and access to the provider's client portal tends to end with it. If nobody downloads the data as you go, part of a ten-year obligation ends up in systems you can no longer log into.

The format counts as well. In a German tax audit, § 147(6) AO allows the auditor to work directly in your systems, to have your staff run evaluations for them, or to ask for the data on a storage medium for their own audit software, and the GoBD (the German tax authority's rules for digital bookkeeping) expect that data to be machine-readable. A PDF of a stock report is fine for reading. Your adviser will usually want a CSV or XLSX they can filter and total.

What to request from the fulfilment provider

Ask by function, because report names and layouts differ from one provider to the next. Find out what each report is called in their system and which columns it contains.

• movement history export (CSV or XLSX), filterable by SKU, date range and movement type
• stock-on-hand as of a chosen date
• receiving reports, including discrepancies
• dispatch report split by channel
• returns and removals report with outcomes and outcome dates
• adjustment, write-off and disposal records
• stock count and variance reports
• copies of delivery notes and proof of dispatch or delivery, where the provider holds them

If one provider runs B2C and B2B fulfilment in Germany together with Amazon replenishment from the same stock, the movement history should cover all three flows in one place. Check that it does before you rely on it.

Put the terms in writing before go-live: the export format, who on your side can pull data and who has to request it, how fast a request is answered, whether there is a charge, how long history stays accessible (including after the contract ends) and a named contact for data requests. A standing monthly routine helps more than any of these. If the previous month's movement history, month-end stock-on-hand and returns report land in a shared folder by, say, the fifth working day, the archive builds itself.

A dry run before the real request

Before your adviser asks for anything, pick one SKU and one month and try to close the loop yourself. Take the warehouse's opening balance, add receipts, subtract dispatches and Amazon transfers, apply the adjustments and see whether you land on the warehouse's closing figure. Then compare the Amazon transfers with what the Inventory Ledger shows as received for the same shipment IDs.

It takes an afternoon. Whatever breaks along the way, perhaps a missing reference, a return booked in the wrong month or a report that can't be filtered by date, is what would have broken under a real deadline. The difference is that you now have time to sort it out with the provider.