Partial Deliveries and Part Invoices in the B2B Shop

The German Civil Code sets out the starting point plainly: the obligor is not entitled to render part performance (Federal Ministry of Justice). A partial delivery is therefore not a supplier's right but something that is agreed - in the framework contract, in the terms of sale or in the individual order. For the interface this means: the permission is a data item, not a gut feeling. A field on the order header, pre-filled from the customer master record and overridable in the checkout, is the technical equivalent of that agreement. Without it, order processing decides every case anew, and the decision cannot be reconstructed afterwards.

For VAT purposes more than logistics hangs on the same agreement. Where the tax is calculated on agreed consideration, it arises at the end of the pre-registration period in which the supplies were carried out; this also applies to part performances, which exist where the consideration for particular parts of an economically divisible supply is agreed separately (Federal Ministry of Justice). Whether a partial delivery is a part performance in that sense is therefore decided by the consideration agreement and not by the packing slip. Commercial law adds that the buyer has to examine the goods without undue delay after delivery by the seller, so far as this is practicable in the ordinary course of business (Federal Ministry of Justice) - with two deliveries there are two notification periods, and the customer needs a separate delivery note per shipment in order to keep them.

The European standard for the electronic invoice knows the case. Field BT-3 carries the code for the invoice type, and the German CIUS XRechnung names eight codes from code list UNTDID 1001 that should be transmitted there: 326 for the part invoice, 380 for the commercial invoice, 384 for the corrected invoice, 389 for the self-billed invoice, 381 for the credit note as well as 875, 876 and 877 for partial and final construction invoices (KoSIT). The code list itself additionally carries 386 for the prepayment invoice (OpenPeppol). Anyone sending a part invoice as 380 loses a piece of information the recipient could have used for mapping.

Two cardinalities are decisive for the chain. The group BG-3 with the reference to the preceding invoice may occur any number of times (0..*) and carries per occurrence the identifier of the preceding invoice in BT-25 and optionally its issue date in BT-26 (KoSIT). A final invoice can therefore name every part invoice that preceded it. The identifier for a referenced despatch advice in BT-16, by contrast, occurs at most once (0..1), as does the actual delivery date in BT-72 (KoSIT). At header level exactly one delivery can be named - a collective invoice covering three delivery notes does not fit in there.

The excerpt shows the places where the mapping hangs: the order number as a bracket around everything, the despatch advice identifier as the reference to the delivery note, the actual delivery date as the point in time of the supply and the order line number per invoice line. German VAT law requires the invoice to state the point in time of the supply or other service anyway (Federal Ministry of Justice); with two partial deliveries those are two different points in time in two different invoices. Anyone issuing both invoices with the date of the second shipment has formally damaged the document. Which deadlines apply from 2027 is covered in the article on the electronic invoicing mandate.

In practice the expensive mistakes do not arise with the first partial shipment but with the second. A line item is invoiced twice because the part invoice from the ERP and the invoice from the shop process both draw on the same quantity. An open quantity is left lying because the order in the shop jumped to "completed" after the first delivery. Or a follow-up delivery is shipped although the customer cancelled the open quantity long ago. All three cases have the same cause: there is more than one place where the open quantity is kept. Every inventory synchronisation across several warehouses knows the same pattern.

The document chain is only finished once it arrives in the customer account. An order shown as partially delivered needs three pieces of information at a glance: which line items were delivered in which quantity, which quantity is open and which date applies to the rest. The state of the whole order is secondary here - the buyer wants to know whether their line item was included, not whether the order counts as completed in a statistic. A progress bar per line item says more about that than a status word per order.

Access to the documents themselves belongs with it. Every delivery note and every invoice sits in the account as a file, sorted by date and grouped per order. The relationship is made visible, not assumed: the invoice names the delivery note it settles, and the delivery note names the invoice as soon as it exists. Anyone who has already connected shipping and logistics interfaces attaches the tracking to the delivery event and not to the order - with two shipments there are two numbers, and storing one of them in the order header costs a query later.

Partial delivery logic can be tested without waiting for the next shortage. The test case stays the same: an order with several line items, one delivery covering part of the quantities, an invoice for it, then the second delivery and the final invoice. What matters is that the check starts at the documents and not at the status fields - a status field says what a system believes, a document says what it has issued.

Partial deliveries are not an edge case to be caught up with in the next release but the normal operation of an assortment with inbound stock. Whether the online channel grows on that or produces queries is decided in three places: a data model that permits several deliveries and invoices per order, documents that name one another, and a customer account that shows the open quantity. We build this chain into existing systems - from connecting to SAP through the middleware to the electronic invoice - and we test it against real documents instead of status fields. An overview of the individual building blocks is available on the page about our services.