Connect a POS system to your shop: stock and receipts

An item sits once on the shelf and once in the database. As long as both figures come from the same source, nothing goes wrong. The moment the till keeps its own stock figure and the online shop keeps another, a gap opens that nobody notices – until an order arrives for a unit that no longer exists. Connecting a point-of-sale system to a shop is therefore not a pure data-transfer exercise. It touches two orders at once: the commercial one, in which stock is supposed to be correct, and the fiscal one, in which every transaction at the till has to be recorded individually, completely and in an unalterable form. Anyone who serves only the first builds an integration that is worth little in a tax audit.

Two channels, one stock figure

Online retail in Germany reached a turnover of 92.3 billion euros in 2025, a rise of 3.9 percent over the previous year (HDE/IFH Cologne). Its share of total retail turnover stands at 13.5 percent (HDE/IFH Cologne). Read the other way round, that means the large majority of turnover still arises at a till, in a room, with a person standing in front of it. The smaller volume of transactions passes through a system that logs every movement anyway. The larger volume passes through a system that is legally obliged to do so.

The share of retailers selling online at all is estimated at around 40 percent (HDE/IFH Cologne). How heavily the online channel weighs differs sharply by sector: in fashion, 44.2 percent of turnover is generated online, while in bricks-and-mortar fashion retail only 11.2 percent of turnover comes from the online channel – less than the 11.7 percent recorded in 2020 (HDE/IFH Cologne). The technical connection is the same in both cases; the question of which channel dominates stock is not.

On top of that, the two channels drift apart in the short term. Turnover in internet and mail-order retail in Germany in July 2026 was 5.6 percent below the previous month in real terms (Federal Statistical Office) and 0.8 percent below the same month a year earlier (Federal Statistical Office). Fluctuations like these do not hit store and shop at the same moment or with the same force. A stock figure reconciled only overnight represents two different realities on such a day – and the shop sells what has long since crossed the counter.

In practice this means till and shop write into the same journal instead of correcting one another. Where an ERP system already holds the item masters, it is the natural place for that; a setup with JTL-Wawi as the leading system is one of the common routes. Where no such instance exists, one of the two sides takes the lead – but explicitly and in writing, not by habit.

What the law requires at the till

A legal decision comes before every technical one. Records made with an electronic recording system must be protected by a certified technical security device consisting of a security module, a storage medium and a uniform digital interface (German Fiscal Code). This duty is no longer a recommendation or a transitional arrangement: under the introductory act the duty applies to calendar years after 31 December 2019 (Introductory Act to the Fiscal Code); cash registers that cannot be upgraded for design reasons and were acquired after 25 November 2010 and before 1 January 2020 were allowed to remain in use until 31 December 2022 at the latest (Introductory Act to the Fiscal Code). Both deadlines have passed.

Behind this sits an older and more general principle. A booking or a record must not be altered in such a way that the original content can no longer be established (German Fiscal Code). For the connection to the shop this is the decisive sentence. It does not forbid correcting a till transaction – it forbids the correction from replacing the original. An interface that silently overwrites a line item already transferred breaches that principle inside the system holding the source data.

• Duty to notify. The type and number of the systems and security devices in use must be reported to the tax authority within one month of acquisition or decommissioning (German Fiscal Code). Replacing a till as part of a shop integration is therefore a notifiable event, not a purely internal IT project.
• Duty to issue a receipt. For business transactions recorded with an electronic recording system, a receipt must be issued and made available to the party involved (German Fiscal Code) – with no minimum amount and regardless of whether the customer wants it.
• Penalty range. Breaches of the duty to protect records with a certified security device can be fined up to 25,000 euros (German Fiscal Code); the 5,000-euro range applies to other tax-endangerment offences, such as issuing factually incorrect receipts (German Fiscal Code). For a breach of the duty to notify, by contrast, the provision sets out no fine at all.
• Exemptions are narrow. The ordinance names six categories of system that do not count as electronic recording systems for these purposes – among them ticket machines, cash dispensers and goods vending machines (Cash Register Anti-Tampering Ordinance). A shop-connected retail till falls under none of them.

These points feed straight back into the interface. If a transaction originates in the till system, is signed there and only then travels into the shop or the ERP, the chain of evidence stays intact. If it originates in the shop and is written back into the till afterwards, it has to be settled which system owns the business transaction and which merely reproduces it. That question can be answered technically, but it has to be answered before the first record – not after the first audit finding.

The receipt as a data object

In the interplay of till and shop, the receipt is the most underrated object. It is not a printout but a record with a defined content that happens to end up on paper most of the time. The ordinance sets out seven mandatory details (Cash Register Anti-Tampering Ordinance): the full name and address of the supplying business, the date the receipt was issued together with the start and end of the transaction, the quantity and nature of the goods supplied or the scope and nature of the service, the transaction number, the consideration and the tax amount attributable to it in a single sum along with the tax rate or a reference to a tax exemption, the serial number of the electronic recording system together with the serial number of the certified technical security device, and the check value of the completed transaction together with the consecutive signature counter.

1. Form of issue. The receipt may be issued on paper or, with the consent of the recipient, electronically in a standardised data format (Cash Register Anti-Tampering Ordinance). Electronic issue expressly requires that consent (Cash Register Anti-Tampering Ordinance); a silent switch to email delivery is therefore ruled out.
2. Data format. The details have to be presented in the tax authority's digital interface for cash register systems (Cash Register Anti-Tampering Ordinance). The format is not a free choice, even where the shop later displays the receipt in a layout of its own.
3. Legibility. Three forms are permitted: legible for anyone without machine assistance, readable from a QR code, or contained in an electronic invoice under the German VAT Act (Cash Register Anti-Tampering Ordinance). The forms stand side by side as alternatives; the QR code on the till slip is therefore the second variant and a permitted substitute for the first.

For the shop integration a clear separation follows. The fiscal receipt is produced by the till and stays there unchanged; at most the shop displays it. The order confirmation, the invoice and the shipment tracking are different documents with different obligations. Mixing those layers and reassembling the till receipt inside the shop creates a second version of the same statement – and with it exactly the risk that the unalterability rule is designed to address.

{
  "source": "pos",
  "transaction": {
    "transaction_number": "2026-000148213",
    "start": "2026-09-09T10:41:07+02:00",
    "end": "2026-09-09T10:41:52+02:00",
    "till_id": "STORE-02-T1",
    "security_module_serial": "TSE-0000-0000-4711"
  },
  "lines": [
    {"sku": "A-10233", "quantity": 1, "amount": 4790, "tax_rate": 19}
  ],
  "stock_postings": [
    {"sku": "A-10233", "location": "STORE-02", "delta": -1}
  ],
  "receipt": {
    "form": "paper",
    "electronic_consent": false
  }
}

The pattern shows the split that matters. The transaction block belongs to the till and stays untouched. The stock_postings block is the only piece the shop genuinely needs, and it carries a delta rather than an absolute value. The receipt block records the form in which the receipt was issued – a detail that later carries the proof of consent if the business moves to electronic receipts.

DSFinV-K, transaction numbers and the security module

What the security device has to record per transaction is likewise settled. Nine details are logged: the time the transaction began, a unique and consecutive transaction number, the type of transaction, the transaction data, the payment methods, the time the transaction ended or was aborted, the check values, the serial number of the electronic recording system and the serial number of the certified technical security device, and the signature counter (Cash Register Anti-Tampering Ordinance). The transaction number has to be assigned so that gaps become apparent (Cash Register Anti-Tampering Ordinance). That absence of gaps is precisely why an interface may neither skip transactions nor renumber them.

The export format is called the tax authority's digital interface for cash register systems. Version 2.3 applies to records from 1 July 2022 onwards (Federal Central Tax Office), and version 2.4 carries the status of January 2024 (Federal Central Tax Office). For an integration project that is more than a footnote: the export is the only view of the till data that an audit can evaluate without knowing the vendor system. Building the integration so that stock movements exist only in the shop and are missing from the till export produces two accounts of the same day.

One layer below, the Federal Office for Information Security sets the technical rules. Technical Guideline TR-03153-1 is published in version 1.1.1 (BSI) and describes the requirements for the technical security device. It builds on guideline TR-03151, which defines the uniform way of addressing the security module (BSI). In practice this means a till system talks to the security module through a standardised interface, and swapping the module is an exchange of components rather than a rebuild of the till.

The second line is the operational figure that counts. Nine of the eleven deviations are explainable, because a reservation in the shop ties up stock without a corresponding till posting. Two are not – and those two are the part worth looking at daily. A reconciliation that reports only a total conceals exactly that distinction.

One account for stock

The cost of untidy stock keeping can be quantified. Shrinkage in German retail was estimated at 5.11 billion euros for 2025 (EHI Retail Institute). Of that, around 780 million euros stem from recording, posting and valuation errors (EHI Retail Institute) – that is, from transactions nobody stole, but which were booked wrongly or not at all. The figures come from a survey of 103 retail companies with 21,225 outlets (EHI Retail Institute), making them a panel value rather than a full census of the trade.

The share attributable to recording errors is the interesting part, because it is the only one an interface influences. No software prevents theft. A return booked twice, a stock transfer that was not transmitted, or a sale that stayed in a buffer during a connection failure and was then dropped are exactly the cases for which an integration either has an answer or does not.

Where items are tracked not just by number but by batch or serial number, the effort grows while the logic stays the same: there too the movement is the object and stock is merely its sum. The specifics of that kind of tracking are described in the article on batch and serial numbers in a B2B shop. And where item data converges from several sources, a PIM system is the place where description, tax rate and unit are defined once – not twice, per channel.

A booking or a record must not be altered in such a way that the original content can no longer be established.

Section 146 (4) of the German Fiscal Code

Payment methods and the volume of receipts

The integration has to handle a volume that is easy to underestimate. German retail counts roughly 20 billion payment transactions per year (EHI Retail Institute). The survey rests on a panel of 499 companies with about 125,000 outlets, covering some 60 percent of bricks-and-mortar retail turnover (EHI Retail Institute). For an individual merchant the absolute figure is irrelevant; the order of magnitude, however, says that an interface generating several calls per transaction looks different on a Saturday afternoon than in a test system.

The mix is shifting too. 19.3 percent of cashless payments at the counter were made by mobile device in 2025, up from 12.8 percent the year before (EHI Retail Institute). Measured by turnover, 32.3 percent goes to cash and 65.1 percent to card payments (EHI Retail Institute); measured by the number of transactions the picture nearly reverses, with 50.5 percent cash against 48.1 percent card (EHI Retail Institute). Card payments carry the turnover, cash payments carry the volume of receipts.

Invoices, retention and deletion

Alongside the till receipt sits the invoice, and it follows different rules. Small amounts qualify for a simplified form: invoices whose total does not exceed 250 euros need only a reduced set of details (German VAT Implementing Ordinance). Above that threshold the full set of invoice details applies – and in B2B trade, increasingly, the structured format as well. The groundwork is on the page about ZUGFeRD and XRechnung and in the article on e-invoicing requirements from 2026.

There is a transitional relief tied to the previous year's turnover: businesses whose total turnover in the preceding calendar year did not exceed 800,000 euros may continue to issue other forms of invoice for supplies made up to 31 December 2027 (German VAT Act). A merchant running both a store and a shop should know that threshold, because it sets the date by which the invoicing route has to be rebuilt – and because that rebuild touches the till integration as soon as invoices originate in the POS system.

• Invoices. A copy of the invoice issued has to be kept for eight years; the period begins at the end of the calendar year in which the invoice was issued (German VAT Act).
• Books and records. Books, records, inventories and annual accounts have to be kept for ten years, accounting vouchers for eight years and commercial and business letters for six years (German Fiscal Code); invoices are kept for eight years under the German VAT Act. The till journal and the records therefore fall under the ten-year period, the individual accounting voucher under the eight-year one.
• Deletion. What is subject to retention must not be deleted – what is not should be. How both requirements fit into a single concept is described in the article on deletion concepts and retention periods.
• Accounting. Till data and shop documents ultimately converge in the same financial accounting; what the handover looks like technically is shown on the page about the DATEV integration and in the article on DATEV in e-commerce accounting.

One point is regularly overlooked: cancellations and credit notes. An online order refunded in the store produces a till transaction with a negative amount and, where an invoice was involved, a correcting document. Both belong in the same chain as the original, not in a separate file. The formal requirements for such documents are covered in the article on cancellation invoices and credit notes; how to reduce returns organisationally is covered in returns management.

What the shop should show about the store

Once stock is kept jointly, a side effect appears that is often worth more than the synchronisation itself: the shop can show what is where. That needs no new data source, only the willingness to make the existing one visible – with an honest label for its age, so a snapshot does not turn into a promise.

Technically, that display also involves machine-readable markup. It is less widespread than one might assume: the Product schema appears on 0.77 percent of all pages examined (Web Almanac 2024), and BreadcrumbList on 5.66 percent (Web Almanac 2024). Marking up availability and pickup location in a structured way therefore sets a shop apart from the majority – provided the marked-up statement matches what stock actually supports. Markup claiming an availability that does not exist in the store does more harm than none at all.

Rebuilding in stages

An integration project rarely fails at the interface and often at the sequence. Transfer first and tidy the master data afterwards, and what gets transferred is errors. The following order has proven itself in projects where store and shop had to keep running in parallel.

1. Unify the item master. One item number per item, one tax rate, one unit of measure, one description. As long as till and shop keep different keys, every stock posting is a mapping exercise with a risk of error.
2. Name the leading system. Exactly one system decides on stock. All others read. That decision belongs in writing, because in an incident it is the only answer to the question of which figure applies.
3. Transfer events, not levels. Postings with a timestamp, a transaction type and an idempotency key. Stock follows from the sum; a full reconciliation runs alongside, not as the main route.
4. Observe before switching over. Two to four weeks of parallel operation with a daily reconciliation. Every deviation is traced to its cause rather than silenced by an adjustment.
5. Add the special cases. Returns, exchanges, transfers between stores, consignment goods, vouchers and deposits. These cases make up the smaller share of transactions and the larger share of deviations.
6. Check against the till export. A DSFinV-K export for a closed period is set against the postings that arrived in the shop and the ERP. Only when both sides show the same volume is the integration accepted.

The last point is the one most often skipped, and the only one that produces evidence. Everything before it is configuration; only comparing two independently generated sets of data shows whether the integration does what it is supposed to. How such a route is built technically is described in our work on custom development and on system integrations.

Keeping one set of books, not two

Connecting a POS system to an online shop is in the end not a question of transfer technology but of bookkeeping. There is one stock figure, not two, and there is one chain of transactions that explains it. Anything that breaks that chain – an overwritten value, a swallowed posting, a second receipt for the same transaction – creates a gap that somebody has to hunt down by hand later.

The legal requirements act less as a brake than as a blueprint. Unalterability, gapless numbering and a prescribed export format are precisely the properties a dependable interface needs anyway. Build them in from the start and the result is an integration that runs quietly in operation and has nothing to explain in an audit that is not already in the data. If you would like an existing route assessed or a new one planned, get in touch through the contact form.

• One system owns stock, all others read it – set down in writing.
• What is transferred are movements with an idempotency key, not absolute values.
• The till transaction stays unchanged in the till; the shop only displays it.
• Return, exchange and transfer each have their own transaction type, not a special case in code.
• Stock reconciliation separates explained deviations from unexplained ones and reports both separately.
• A DSFinV-K export serves regularly as an independent counter-check against the shop side.