On 30 December the warehouse counts, on 31 December the financial year closes, and on 2 January the shop is supposed to show stock levels that hold up. In between sits a window in which postings are locked while orders keep arriving. If that window is only discussed shortly before it starts, it pushes the counting variance into January, where it is hard to attribute between back orders, returns and the first invoice run of the new year. This article describes which decisions should be taken now so that stock, number ranges and the document chain line up on the balance sheet date, and which of them belong in the interface rather than in a verbal agreement. Anyone having their ERP and inventory connected to the shop settles the behaviour during the cut-off window when the interface is designed, not on the cut-off date itself.
Key takeaways
- An inventory describes a state at a point in time, an interface describes a flow. The freeze window is the rule that connects the two.
- A shifted count keeps the counting out of the Christmas season, but requires an unbroken record of movements between counting day and cut-off date (German Commercial Code).
- Stock is not one field but four: counted, posted, reserved, displayable. A status field in the stock message saves the queries in January.
- Buffer messages during the freeze window instead of discarding them, and run a full reconciliation after release instead of deltas.
- Invoice numbers may restart at the turn of the year, but they must stay unique; two systems on the same series produce duplicates (German VAT Act).
- The freeze window, the buffering logic and the variance rule belong in the process documentation, inventories belong in the archive for ten years (Federal Ministry of Finance, German Commercial Code).
Why the cut-off date hits the interface
The obligation is old and briefly worded: every merchant has to draw up an inventory for the close of each financial year, and the financial year may not exceed twelve months (German Commercial Code). For a business without online sales this is a task for logistics and accounting. As soon as a shop hangs off the ERP system, it becomes a task for the interface. An inventory describes a state at a point in time, while the interface represents a flow: orders, reservations, delivery notes and credit notes keep running even while the warehouse is being counted. The question is therefore not whether the shop stays reachable during the count, but which quantities it may show in that period and which postings it may trigger. Anyone who does not decide this in advance decides it implicitly through the default behaviour of the systems in use.
The timing is additionally awkward because it coincides with the strongest quarter of the year. According to the industry association, gross goods turnover in German e-commerce with end customers reached 83.1 bn euro in 2025 after 80.6 bn euro the year before (bevh); in the third quarter of 2025 alone orders reached a value of 17,960 mn euro (bevh). In fashion and consumer electronics in particular, an older analysis by the same association, as at 2023, records that more than a third of annual turnover is generated in the Christmas quarter (bevh). A freeze window that costs two hours in July costs a multiple of that at the end of December, not in computing time but in orders that are not cleanly reserved during it. The length of the window is therefore not a technical remainder but a commercial decision, and it depends on the counting method chosen.
Three simplifications, three burdens for the interface
The German Commercial Code requires the inventory but does not prescribe that every shelf be touched on 31 December. Besides the physical count on the cut-off date, several simplified procedures are available (German Commercial Code). First, the stock of assets by type, quantity and value may be determined with the help of recognised mathematical and statistical methods on the basis of samples. Second, the physical count on the cut-off date is not required where another procedure complying with the principles of proper accounting secures the stock by type, quantity and value, which is the perpetual inventory. Third, a special inventory may be drawn up for a day within the last three months before or the first two months after the close of the financial year. Each of these variants places a different demand on the interface.
| Procedure | Legal basis | Effect on the shop | Demand on the interface |
|---|---|---|---|
| Count on the cut-off date | Sec. 240 (2) HGB | Short, hard freeze window around 31 December | Hold the stock message, let reservations keep running |
| Sample-based inventory | Sec. 241 (1) HGB | Shorter counting time, same freeze logic | Hand over sample selection and extrapolation with a log |
| Perpetual inventory | Sec. 241 (2) HGB | No common freeze window, continuous counts instead | Location-level movement data and document chain across the whole year |
| Shifted inventory | Sec. 241 (3) HGB | Counting in October or January instead of the peak season | Roll-forward and roll-back need every single movement |
| Fixed-value method | Sec. 240 (3) HGB | Concerns fixed assets and supplies, rarely shop articles | Plan a physical count every three years |
For businesses with online sales the shifted inventory is the usual case, because it keeps the count out of the Christmas season. The price for that is written into the law: the special inventory only holds if a procedure complying with the principles of proper accounting makes the stock at the close of the financial year properly valuable (German Commercial Code). Rolling forward means that every movement between counting day and cut-off date stays recorded and attributable, including the ones that arise in the shop and only reach the ERP later. This is exactly where interfaces that aggregate movements instead of transferring them individually take revenge: whoever transfers only the balance can no longer resolve the gap afterwards. How stock stays consistent across several locations is covered in the article on inventory sync across multiple warehouses.
The counting method determines the data model, not the other way round
Plan the freeze window instead of enduring it
A freeze window is not a maintenance window. During maintenance the system is gone; during a freeze window it is present but behaves differently: it accepts orders but no longer changes stock, or it changes stock but no longer reports it outward. That distinction has to be described before the cut-off date, otherwise everyone involved interprets it differently. In practice the window consists of three sections: the run-up, in which open documents are cleared and goods receipts and issues are completed, the counting time itself, and the run-out, in which variances are posted and stock is released again. Each section calls for different interface behaviour, and each section needs a switch that someone deliberately flips.
- Clear open documents. Picking runs, goods receipts and returns created before the counting day are either posted or explicitly moved into the run-out.
- Freeze the stock message. The shop keeps the last transferred value and reports no new quantities instead of dropping to zero.
- Let reservations keep running. Incoming orders reserve against a buffer so that selling does not stop and the counted quantity still stays stable.
- Buffer messages instead of discarding them. Outgoing stock events run into a queue that is processed in the original order after the window.
- Count and log. Count lists, recounts and corrections receive a timestamp, a user and a document reference; under the GoBD later changes have to be made in such a way that the original content and the fact of the change remain recognisable (Federal Ministry of Finance), which is the evidence later on.
- Assess the variances. Deviations per location are checked against a tolerance band defined in advance; anything beyond it goes into a recount, not into a collective posting.
- Release the stock. Only after the variance posting is the stock message armed again, and then with a full reconciliation instead of deltas.
- Watch the run-out. The first days after the window belong under observation, because ordering errors show up there and not on the cut-off date itself.
The fourth point is the one most frequently missing. If stock events are discarded during the window instead of buffered, what is missing after release is precisely the movement that would explain the difference between counted and posted stock. A queue with retries and a unique operation key solves this without anyone reworking it by hand; how that works without duplicate postings is described in the article on idempotency and retry strategies in integrations. The eighth point requires someone to look: monitoring the interfaces with metrics for queue length, retries and the age of the last stock message shows ordering errors within hours rather than weeks.
What the shop may show on the cut-off date
The most common false assumption during the cut-off window is that there is one stock figure. In fact there are at least four quantities, and in December they drift further apart than during the rest of the year: the physically present stock, the posted stock in the ERP, the quantity reserved for orders and the quantity the shop displays as available. As long as all four are derived from one field, every count is a bet. It is therefore sensible to cut the stock message so that it carries these figures separately and additionally carries a status saying how reliable the value currently is. A shop that knows a location is being counted right now can display a delivery time instead of a unit count, rather than asserting a number that nobody can currently vouch for.
Counted quantity
The result of the physical count with counting day, counter and location. It is the starting value for the roll-forward and stays unchanged even when postings continue afterwards.
Reserved quantity
Everything ordered in the shop but not yet shipped. It explains the difference between shelf and book stock and belongs in a field of its own during the freeze window.
Displayable quantity
The number the shop may show, derived from the counted quantity, reservations and a safety deduction that can be set per location.
A status field in the stock message costs little and saves queries in January. It distinguishes at least between a live message, a frozen value during the count and a value that comes from a full reconciliation after release. Downstream systems tie their behaviour to it: in the frozen state the shop hides the unit count and shows an availability level, the marketplace connection reduces the quantity reported, and monitoring does not treat a missing update as a fault. For articles with batches and serial numbers there is the added point that counting happens per batch and aggregation to the article only comes afterwards; anyone who does not separate the level in the message loses exactly the information that would later explain a variance. The same applies to businesses working with units of measure and pack sizes: counting happens in cartons, selling happens in units.
{
"article": "40-2517-KH25",
"location": "NORTH",
"as_of": "2026-12-30T18:00:00+01:00",
"status": "frozen",
"quantities": {
"counted": 412,
"posted": 418,
"reserved": 37,
"displayable": null
},
"count": {
"document": "INV-2026-NORTH-0007",
"counting_day": "2026-12-30",
"method": "shifted"
},
"display": {
"show_units": false,
"hint": "show delivery time instead of unit count"
}
}The stock message calls for a second decision that is frequently only taken in January: from which deviation onwards a line is recounted. A tolerance band per location and product group makes that threshold visible in advance and takes the arbitrariness out of the variance posting. A relative band makes sense, because a deviation of five units on a fast mover means something different from the same deviation on a spare part with two movements a year. Whoever sets the band also settles what happens to the lines beyond it: a recount by a second person, release by the warehouse management, and only then the posting. Precisely this chain belongs in a log, because it later explains why a quantity was corrected. For the interface this means that the release of a location does not hang on the end of the count but on the end of the recount: as long as lines are open, the location stays in the frozen state and the shop keeps showing the availability level instead of a quantity. In case of doubt that costs half a day more freeze time, but it saves the correction posting in February, for which nobody has the count lists to hand any more. Anyone bundling several locations into one message loses that control again, because band and recount apply per location. A report per location with deviation, band and status is therefore not an extra but the acceptance document for the cut-off window.
Number ranges and the document chain on 1 January
On 1 January many businesses switch their number ranges: sales orders, delivery notes, invoices and credit notes get a new prefix or start again at one. That is permissible as long as the number still does its job. The German VAT Act requires an invoice to carry a sequential number with one or more series of figures which is assigned once only by the issuer of the invoice to identify the invoice (German VAT Act). Several series of figures are therefore explicitly allowed, for instance per sales channel or per legal entity; uniqueness is the condition. It becomes a problem when two systems serve the same series: if the shop assigns document numbers and the ERP assigns them too, duplicates arise at the turn of the year because both sides are reset independently of each other.
eine fortlaufende Nummer mit einer oder mehreren Zahlenreihen, die zur Identifizierung der Rechnung vom Rechnungsaussteller einmalig vergeben wird (Rechnungsnummer)
The clean solution is to give authority over each document type to exactly one system and let the other side only adopt the number. In a shop context that usually means: the shop assigns the order number, the ERP assigns sales order, delivery note and invoice. The mapping runs through a foreign key column, not through a naming convention. Where orders break down into several deliveries and documents this becomes particularly visible; how partial deliveries and part invoices can be mapped across the turn of the year is a topic of its own. With electronic invoicing there is the added point that the transition is limited by statute: for a supply carried out after 31 December 2024 and before 1 January 2027 the invoice may still be transmitted on paper and, subject to the recipient's consent, in an electronic format that does not meet the e-invoicing requirements; for issuers with no more than 800,000 euro total turnover in the previous year the same applies for a further year (German VAT Act). Anyone placing the e-invoicing mandate on the turn of the year should not put the number-range switch into the same week.
- Settle authority per document type. For order, sales order, delivery note, invoice and credit note it is written down which system assigns the number.
- Foreign keys instead of conventions. Every document line carries the source system's number in a field of its own, not inside a composed string.
- Separate series per entity. Several series of figures are permissible, they only have to be clearly distinguishable.
- Plan for transition documents. Orders from the old year that are invoiced in January need a rule saying which range applies.
- Rule out jumps backwards. A counter that is reset at the turn of the year must not draw again in the old range.
- Test run with a real date jump. In a test environment with dependable test data the switch is played through in full once before it happens in production.
Prices, accounts and master data at the start of the year
It is not only numbers that change on 1 January. Price lists, scales, promotional discounts, freight cost rules and in part tax codes get a new validity date. The usual mistake is to import this data on the evening of 31 December, because it then takes effect immediately. A better answer is a data model that carries validity periods: the price for the new year already sits in the system in December but only takes effect from its start date. That moves the risky action from New Year's Eve to a normal working day, and the comparison between ERP and shop can be run beforehand. Anyone maintaining prices across customer and scale levels needs validity on every level, otherwise the wrong line wins at the turn of the year.
The same thought applies to the handover to accounting. Accounts, cost centres and tax codes are master data with validity, and the allocation of a transaction depends on the service date, not on the document date. If the handover to accounting runs automatically, January should include a reconciliation that checks the first postings of the new year against the source document on a sample basis. Payment reconciliation in the ERP also deserves its own round in January, because payments from December meet documents from the old year and payout runs arrive bundled across the turn of the year. Anyone running a DATEV integration additionally clarifies until when documents from the old year may be delivered and how a subsequently corrected document is marked.
An import without a validity date is an immediate change
Evidence: process documentation and data access
Whatever happens automatically during the cut-off window has to be traceable afterwards. The German Fiscal Code requires postings and the other necessary records to be made individually, completely, correctly, in a timely manner and in an orderly fashion (German Fiscal Code). The GoBD administrative principles make this concrete for data processing systems: for every system there must be a clearly structured process documentation from which the content, structure, sequence and results of the procedure are fully and coherently apparent (Federal Ministry of Finance). The version in force applies from 1 April 2024 (Federal Ministry of Finance). For stocktaking this means concretely: the sequence of the freeze window, the buffering and retry logic of the interface and the rule for variance postings belong in writing, ideally where the process documentation for interfaces is maintained anyway.
The second part concerns retention. Inventories belong to the documents that have to be kept for ten years, other documents for six years (German Commercial Code). Invoices have to be kept for eight years under the German VAT Act (German VAT Act). This concerns not only the signed count protocol but also the machine records that explain the stock. In the course of an external audit the tax authority may inspect the stored data, demand a machine evaluation according to its own specifications, or request the data in a machine-evaluable format (German Fiscal Code). Anyone clearing out movement data from the interface after two years may lose the evidence for a roll-forward. How deletion periods and retention obligations can be brought together across shop, ERP and accounting is covered in the article on the deletion concept across system boundaries.
Accounting that is rejected gets estimated
Typical errors in the cut-off window
- Stock drops to zero instead of freezing. If the stock message stops, some shop and marketplace systems read that as sold out and withdraw articles from sale.
- Deltas after release. After the window the system starts with differences instead of a full reconciliation; every movement lost during the freeze then stays in the stock permanently.
- Counting without a location reference. A total quantity without a location cannot be checked against a roll-forward and explains no variance.
- Returns as a blind spot. Returns arriving during the count frequently land in neither of the two stock figures, neither the counted nor the posted one.
- Reservations treated as stock. If the reserved quantity is deducted from stock instead of kept separately, a variance appears on the counting day that does not exist at all.
- Freeze window only in the ERP. If the freeze is set in the ERP but unknown in the shop, the shop keeps selling against a stock figure that nobody is currently rolling forward.
Five of these six points are design errors, not operating errors. They arise because the freeze window does not exist as an operating state and therefore cannot be tested either. A business that models the state explicitly can play it through in a test environment in October, let the queue fill up and measure the release. That is the same thought as with an ERP outage fallback: a planned exceptional state is manageable, an unplanned one considerably less so. The difference is that the date for the stocktake is one you set yourself.
A schedule from September to January
The sequence in time is less strict than the sequence in substance, but a few dependencies are fixed. The counting method has to be settled before the counting date, the counting date before staff planning, and the interface changes have to be in production before the Christmas season, because between the end of November and the end of December nobody typically wants to touch the stock logic any more. That produces a schedule which starts in September.
| Period | Task | Result |
|---|---|---|
| September | Settle counting method and counting date, agree locations and tolerance band | Decision documented, effort estimated per location |
| October | Implement and test the freeze window as an operating state in the interface | Status field, queue and full reconciliation proven in the test environment |
| Early November | Create number ranges, price lists and validity dates for the new year | Data ready with a start date, without taking effect yet |
| Mid-November | Change freeze for the stock logic, sharpen the monitoring | Production state frozen, metrics running and being read |
| December | Count, assess variances, release stock after a full reconciliation | Count protocols archived with document, time and user |
| January | Check the full reconciliation, control the first postings of the new year | Roll-forward evidenced, deviations attributed |
The change freeze in mid-November is the point that gets discussed most. It costs flexibility, but it prevents the combination that becomes most expensive in December: new stock logic and a high order volume at the same time. Anyone running a middleware between shop and ERP can limit the freeze to the stock and document paths and let other topics keep running; without that separation the freeze puts the whole project on ice.
What we take on during the cut-off window
We set up the freeze window as an operating state of its own: a status field in the stock message, a queue with retries, a full reconciliation after release and an explicit rule for reservations during the count. Added to that are the number-range switch with a transition rule, the validity dates for prices and master data, and the description of the sequence for the process documentation. During the counting time we accompany the window with an eye on queue length, retries and the age of the last message, so that an ordering error shows up in December and not in February. An overview of the range is given on the page about our services.
Sources and evidence
Related Articles
Connecting Lexware Office to the shop: vouchers and items
How shop orders become vouchers and shop products become master data in Lexware Office: field mapping, the limits of the interface and the pace it demands.
Batches and Serial Numbers Between ERP and Shop
Batches belong to the movement, serial numbers to the single unit: data model, EU traceability rules, GS1 application identifiers and the recall as the test.
Units of Measure and Pack Sizes from ERP to Your Shop
Separate base, stock, selling and purchase units, pull conversion factors from the ERP, and map stock, minimum quantities and unit prices correctly.