Invoice from shop or ERP? Setting the leading system

Under German VAT law, an invoice is any document used to bill a supply of goods or services, regardless of what the document is called in business dealings (Section 14(1) UStG). For the architecture, this sentence matters more than it sounds. Whether the shop calls its PDF “purchase receipt”, “order summary” or “invoice” does not decide whether it is an invoice. If the document shows the price and the tax for delivered goods and goes to the customer, classifying it as an invoice is the obvious reading. Anyone who additionally sends an invoice from the ERP has then put two billing documents for the same transaction into circulation.

The invoice number is one of the mandatory details. The law requires a sequential number based on one or more series of numbers, assigned once by the issuer to identify the invoice (Section 14(4) no. 4 UStG). Three terms in it carry the architecture question: “once”, “issuer” and “one or more”. Once means that no number may occur twice, not even in two different systems of the same company. The issuer is whoever creates the invoice, and therefore also whoever draws the number. And “one or more series” explicitly allows shop and ERP to keep their own ranges, as long as they do not overlap.

The tax administration spells this out in the VAT Application Decree (UStAE). It is left to the issuer how many and which separate number ranges are created, in each of which an invoice number is assigned only once; ranges for areas separated by time, geography or organisation are permitted (UStAE 14.5 para. 11). It must be ensured, however, that every invoice can be assigned easily and unambiguously to its number range and that the number is unique. In practice, this means one prefix per issuing system or channel, such as RS for shop invoices and RE for ERP invoices, and no two counters serving the same prefix.

Gaps are therefore not a formal error. They should still be explainable, because a machine-generated range with unexplained gaps can raise questions in a tax audit. Between shop and ERP, gaps typically arise where one system reserves a number and the process then aborts, for example because the hand-over to the ERP fails. If the number is only assigned when the document is actually created and aborted attempts are logged, every gap can be accounted for. There is an exception for small amounts: small-amount invoices up to EUR 250 (Section 33 UStDV) need no sequential number (UStAE 14.5 para. 14). However, this simplification of the small-amount invoice does not apply to distance sales under Section 3c UStG (Section 33 UStDV), and many shops also deliver to consumers in other EU countries.

The solution is not a system choice on a grand scale but a decision per document type. For order, order confirmation, delivery note, invoice, invoice correction and self-billed credit note, it is laid down in writing which system creates the document and assigns the number. The other system takes over the number as a foreign key, displays it and, where needed, sends an identical copy, but does not create a second document itself. The same principle applies to master data; how a leading system resolves conflicts between ERP and shop is described in the article on bidirectional synchronisation.

For the invoice, there are three viable set-ups and one that does not hold. Which one fits depends less on taste than on where the data lies that an invoice needs: customer master with VAT identification number, tax determination, payment terms, shipments and supply data. The table puts the three set-ups side by side.

The fourth set-up – both systems write, depending on who comes first – is often the starting point of a clean-up project in practice. It rarely arises on purpose, but through a shop extension that sends an invoice after checkout and an ERP configuration that nobody adjusted when the integration was built. Split by channel, by contrast, does not mean that two systems may bill the same order. The boundary runs along the channel or the customer group, and every single order falls clearly on one side.

A business that makes a supply is entitled to issue an invoice. It is obliged to do so if it supplies another business for its business or a legal person; the invoice must then be issued within six months of the supply (Section 14(2) UStG). If the supply goes to another business and both are established in Germany, it must be issued as an electronic invoice. When ordinary goods are sold to consumers, there is no obligation to invoice. If an invoice is issued anyway, an e-invoice may only be used with the recipient's consent (BMF letter of 15 Oct 2025).

For the architecture, this means: in B2C business the invoice is a service that should arrive quickly, and the shop knows basket, payment and email address. In B2B business it is an obligation with a deadline and a format, and the details for it usually lie in the ERP: debtor account, VAT identification number, payment terms, a different billing address and the customer's purchase order reference. How tax rates and reverse charge cases get from the ERP into the shop is described in the article on tax determination in the B2B shop.

Across borders it gets tighter. For an intra-community supply, the invoice must be issued by the fifteenth day of the month following the month of the supply, and it must show the VAT identification numbers of both parties (Section 14a(3) UStG). A shop that accepts B2B orders from other member states must therefore either keep the customer's verified number itself or leave the invoice to the ERP, which holds it in the debtor account. Anyone who mixes both ends the month with a list of open orders for which nobody knows which system monitors the deadline.

An issued invoice is neither deleted nor overwritten. An entry or record may not be altered in such a way that its original content can no longer be determined (Section 146(4) AO). A correction is made by a document that refers specifically and unambiguously to the invoice (Section 31(5) UStDV). This is regularly the case if the document states the sequential number of the original invoice; a new invoice number for this document is not required (UStAE 14.11 para. 1).

Legally, the issuer of the invoice is the company, not the software. A correction can only be made by the issuer of the invoice (UStAE 14.11 para. 2) – for the shop and the ERP of the same retailer, that is the same company in both cases. Technically, however, the reference requirement leads to a clear rule: the correction is created in the system that knows the original invoice, its number and its line items. An ERP that cancels a shop invoice would have to take over the number, date and amounts of the shop invoice instead of deriving a new document from its own sales order. For e-invoices, the correction must also be made in the prescribed form using the corresponding invoice type (UStAE 14.11 para. 1). In XRechnung, field BT-25 carries the identifier of the preceding invoice that is referred to (KoSIT).

The word “Gutschrift” is a special case in German. For VAT purposes, a Gutschrift is a self-billed invoice that the recipient issues under a prior agreement (Section 14(2) UStG), and it must carry the term “Gutschrift” (Section 14(4) no. 10 UStG). The commercial credit note for a return is something else: it corrects your own invoice. The mere label “Gutschrift” does not by itself trigger Section 14c UStG (UStAE 14c.1 para. 3). For clean data, it is still worth keeping both document types separate so that the returns process creates the right one; how returns run between shop and ERP is described in the article on the RMA process.

An electronic invoice is an invoice that is issued, transmitted and received in a structured electronic format and enables electronic processing (Section 14(1) UStG). Formats that comply with the European standard EN 16931 are permitted; their use is not restricted to national formats (BMF letter of 15 Oct 2025). The transitional rules expire in stages. For supplies until the end of 2026, invoices may still be sent on paper or, with the recipient's consent, in another electronic format. For supplies in 2027 this only applies if the issuing company's total turnover in the previous year did not exceed EUR 800,000; EDI procedures remain permitted with consent until the end of 2027 (Section 27(38) UStG).

Whoever issues the invoice must therefore master the format. A shop that has so far rendered a PDF needs a route to XRechnung or a hybrid format for domestic B2B customers. With a hybrid format, the invoice data in the structured part forms the leading part; in the event of deviations it takes precedence over the image part (BMF letter of 15 Oct 2025). The specification describes the invoice number in field BT-1 as a unique identifier that identifies the invoice in the seller's system (KoSIT). For the architecture, this means the number comes from the system that issues – not from the one that later passes the file on.

The format keeps evolving. The preliminary version of the XRechnung 4.0 specification was published in September 2026, and the final version is expected to be published in spring 2027 (KoSIT). The issuing system has to follow such version changes, and that is a decision criterion of its own: if the ERP is old and the shop is young, middleware can also produce the e-invoice from the ERP data within the ERP's number range. Which formats and deadlines apply in detail is covered in the article on the e-invoice mandate 2027; how we approach implementation from ERP and shop is described on the e-invoicing page.

Moving to a leading invoicing system is usually not a large migration project, but it needs an order of steps. Switching off the shop invoice first and configuring the ERP afterwards leaves a window without documents; doing it the other way round leaves one with duplicates.

Testing uses the awkward cases, not the normal case: a partial delivery across the turn of the month, a cancellation after a partial return, a marketplace order with self-billing, a B2B order from another member state and a retry after a timeout. Only when none of these cases produces two invoices does ownership really lie with one system.