A specialist wholesaler sells on account, and the ERP holds a short code such as ZB01 on the customer record. Behind it sit four pieces of information at once: the date the clock starts from, the net term, the discount rate and the discount period. The buyer sees none of that in the shop. They pick purchase on account, confirm, and two days later receive a document with terms that appeared nowhere during the ordering process. Net terms are therefore the last major figure in B2B checkout still carried as paper knowledge, while price, stock and tax have long been coming out of the integration. This article shows how the terms code is read, translated into plain text and a date at checkout, written back to the sales order and the invoice, and resolved again for the discount deduction in the payment integration, including the cases in which the agreed period does not hold up legally.
Key takeaways
- The payment terms code is a master data field on the customer record and carries four pieces of information at once: baseline date, net term, discount rate and discount period. It is called ZTERM (SAP), Payment Terms Code (Dynamics 365 Business Central) or Zahlungsziel (JTL); the shop has no equivalent field out of the box.
- Checkout shows no code, it shows plain text and a date. Converting a period of 30 days into a due date belongs in the middleware, because only there is it settled which document date starts the period.
- An agreement of more than 60 days is only effective between businesses if it has been expressly made and is not grossly unfair to the creditor (Section 271a paragraph 1 German Civil Code). Terms coming out of the ERP therefore belong behind a guard before they are displayed, not unchecked on the document.
- An early payment discount is a condition, not a rebate. The invoice amount stays uncut; only the payment arriving within the period changes the taxable amount, and the tax amount then has to be adjusted (Section 17 paragraph 1 German VAT Act).
- For electronic invoices between German business partners, validation rule DE-R-018 prescribes a fixed text pattern in the payment terms field (Peppol BIS Billing 3.0). A freely worded discount clause fails there.
What the terms code in the ERP really carries
The customer record rarely holds a period, it holds a reference. The field carries a short code, and only the terms table behind it resolves what that means: which date starts the clock, how many days pass until the amount is due, whether there are one or two discount tiers and whether counting runs day by day or to the end of the month. In SAP the field is called ZTERM, in Dynamics 365 Business Central Payment Terms Code, in JTL simply Zahlungsziel; the names differ, the structure barely does. Transferring only the display text of the terms loses exactly the part you can compute with: in the shop the code becomes a line of description at best, and the baseline date becomes nothing at all. A SAP integration and a Dynamics integration therefore should not deliver the code but the resolved terms with all four fields.
In the shop, by contrast, invoice is a payment method, an option next to prepayment and direct debit. That is exactly where the break sits: the payment method says how the customer pays, the terms say by when and at what deduction. As long as the two are not brought together, the customer orders on one assumption and receives a document on another. The follow-up questions land with inside sales, and they land for the customers with deviating terms, which typically means the largest ones. Whether buying on account is permitted at all is settled by the credit limit check from the ERP; on what terms is decided by the payment terms code. Both checks belong in the same step of the checkout, because they need the same answer from the same master record.
Terms code
The short code on the customer record, often different per sales organisation or distribution channel. It is a reference to a table, not a value, and has no place in the shop.
Baseline date
The reference day the count starts from: document date, invoice date or service date. The shop produces an order date, which rarely coincides with any of them.
Net term
The number of days until the amount is due in full. At checkout it appears not as a number but as a date the buyer can put into their calendar.
Discount rate
The deduction in percent, frequently in two tiers. It does not act on the invoice amount but on the amount payable when the payment arrives in time.
Discount base
The part of the amount the deduction refers to. Freight, assembly and rebates already granted are often excluded; that sits in the terms, not in the shop.
Payment method
The selection made at checkout. It limits which terms can apply at all and is the only one of these figures that originates in the shop itself.
From the code to a date at checkout
Checkout needs three values: a sentence of plain text, a due date and, where a discount tier has been agreed, a second date with the matching amount. All three originate in the middleware and not in the shop, because only there do the terms and the document date sit together. The most common trap is that very document date: the shop produces an order date, the ERP an invoice date, and with drop shipments or collective invoices several days lie between them. If the period is counted from the order date in the shop and from the invoice date in the ERP, the displayed date differs from the printed one without any error appearing in a log anywhere. Time zones add to this: a timestamp in UTC can sit a day before the local date, and with a period counted day by day that is a full day of difference, as the article on timestamps in ERP interfaces sets out in more detail.
The date belongs at checkout, the day count belongs in the terms
read customer: payment_terms_code, credit_limit, payment_method
resolve code -> baseline_date_type, net_days, discount_rate, discount_days, discount_base
baseline_date = invoice date if present, otherwise document date # never the order date
due_date = baseline_date + net_days # calendar days, local time zone, not a UTC day
discount_date = baseline_date + discount_days
discount_amt = discount_base * discount_rate # decimal type, never applied to the total
if net_days > 60:
flag the terms for approval and do NOT show them at checkout
if payment_method != invoice:
drop the terms and show the conditions of the selected payment method
return: plain text, due_date, discount_date, discount_amt (for information)An early payment discount is a condition, not a rebate
The most widespread mistake in an integration is deducting the discount in the cart. It looks friendly and produces an invoice nobody can settle: if the customer pays later than agreed, the difference is missing, and the ERP carries an open item that neither the dunning run nor payment matching can handle cleanly. The correct approach is separation. The invoice amount stays uncut, the discount amount sits next to it for information, and only a payment arriving within the period triggers the reduction. In VAT terms this is no formality: if the taxable amount for a taxable supply has changed, the trader who carried out that supply has to adjust the tax amount owed on it (Section 17 paragraph 1 German VAT Act), and the adjustment is to be made for the period in which the change occurred. It therefore belongs to the incoming payment, not to the order. Keep this separate from the question of which tax rate applies to the price; that is covered by the article on tax determination in the B2B shop. How the receipt is matched to the open item is described in the article on reconciling payments with the ERP.
- Define the discount base: freight, assembly and surcharges are frequently not eligible. The base comes from the ERP as its own amount, not as a share the shop works out for itself.
- Map both tiers: many terms carry a second discount tier with a smaller rate and a longer period. If only the first is transferred, the customer loses an option they hold contractually.
- Show the deduction for information: at checkout, state the amount that remains outstanding when payment is made in time, clearly separated from the invoice amount. Two figures, not one reduced figure.
- Classify partial payments: a payment below the invoice amount is either a discount taken within the period or a short payment. The date of receipt decides which, not the size of the amount.
- Report unauthorised deductions: if a customer takes the discount after the period has expired, a residual claim arises. It belongs in the ERP and in the customer account as a transaction, not in a folder on an inside sales desk.
When the agreed period does not hold legally
Not every set of terms maintained in the ERP survives on the document. Between businesses, an agreement under which the creditor may demand performance of a claim for payment only after more than 60 days from receipt of the consideration is only effective if it has been expressly made and is not grossly unfair to the creditor (Section 271a paragraph 1 German Civil Code). Where the debtor receives an invoice after receipt of the consideration, the time the invoice is received takes the place of receipt of the consideration; the invoice date is therefore not only a technical figure but a legal one. Where the claim only falls due after inspection or acceptance of the consideration, a separate limit of 30 days applies to the inspection or acceptance period under the same conditions (Section 271a paragraph 3 German Civil Code). Towards public sector buyers the limits are drawn more tightly.
For the integration this means: a period is not a value you pass through, it is one you measure. Terms beyond the limit are flagged and put forward for approval instead of appearing at checkout, and because such terms usually hang on a handful of large customers, the list is short and can be worked through once. A guard in the sync that holds every new or changed set of terms against the limit costs little compute time and prevents an agreement from surfacing only in a dispute. The same place is suited to the second check, namely whether the terms fit the selected payment method at all: net terms next to a prepayment are a contradiction that the document otherwise has to carry. Neither replaces legal advice, it only moves the question to the point where it can still be settled cheaply.
| Criterion | Without terms integration | With terms integration |
|---|---|---|
| Display at checkout | payment method invoice, no period | plain text plus due date |
| Early payment discount | visible only on the document | shown at checkout for information |
| Baseline date | order date from the shop | invoice date from the ERP |
| Statutory limit | unchecked from the master record | guard against the statutory limit |
| Incoming payment | short payments searched by hand | deduction within the period matched automatically |
| Customer account | open items only in the ERP | due date and discount period visible per document |
Default, interest and the flat sum
If payment fails to arrive, a chain begins that also needs data. The debtor of a claim for payment is in default at the latest if they do not pay within 30 days of the due date and of receipt of an invoice or equivalent statement of payment (Section 286 paragraph 3 German Civil Code). In legal transactions in which no consumer is involved, the interest rate for claims for payment is nine percentage points above the base rate (Section 288 paragraph 2 German Civil Code). The base rate is set twice a year and has stood at 1.52 percent since 1 July 2026 (Deutsche Bundesbank); for that period the two figures together give 10.52 percent. Because the rate changes twice a year, it belongs in the ERP as a maintained value and not as a constant in the source code of the interface.
There is also a flat sum: where the debtor of a claim for payment is in default and is not a consumer, the creditor additionally has a claim to payment of a flat sum of 40 euro (Section 288 paragraph 5 German Civil Code). The dunning chain itself belongs in the ERP and not in the shop; the shop displays the state. A customer account that carries open items with due date, discount period and dunning level takes exactly those calls off the inside sales desk that otherwise pile up at every month end, and it turns the discount period into a visible incentive rather than a line in the small print. How order and document status are pulled live from the leading system for that purpose is described in the article on order status in the B2B customer account.
Terms per customer, contract and part invoice
A set of terms rarely applies to a whole customer. It hangs on the sales organisation and the distribution channel, on a blanket order or on a single order type, and in case of doubt the more specific one wins. The interface has to know this order of precedence, otherwise the shop shows the terms of the master record while the ERP pulls those of the contract, and the deviation only surfaces on the document. Where call-offs from a blanket order are running, this is the rule rather than the exception; how such call-offs are represented in the shop is covered by the article on blanket orders and call-offs. In wholesale there is the added fact that entire customer groups carry their own terms, which an integration of wholesale processes has to represent anyway.
The second case is partial deliveries. If an order is broken into two deliveries and two invoices, two periods arise with two due dates and two discount periods, and the balance in the customer account is no longer a figure but a list. The shop has to be able to show that list, otherwise a correctly paid part invoice looks like an outstanding claim and triggers exactly the call the integration was meant to save. The article on partial deliveries and part invoices describes the document chain for that. For the terms, one simple rule applies: every invoice carries its own, and none inherits a period from the original order.
Terms are a data field, not a footnote
Early payment discounts in the electronic invoice
In the European standard for electronic invoicing, payment terms are a text field, that is, a textual description of the payment terms that apply to the amount due for payment. For traffic between German business partners plain prose is not enough, which is why a dedicated validation rule prescribes a fixed pattern. Under it, information on cash discounts for prompt payment is to be provided in the payment terms field like this: first segment SKONTO, second segment the number of days as TAGE=N, third segment the percentage as PROZENT=N (Peppol BIS Billing 3.0, rule DE-R-018). The percentage is written with a dot and two decimal places, each entry begins and ends with a hash sign, everything is in capital letters, and additional spaces are not allowed. Two percent at ten days therefore becomes the string #SKONTO#TAGE=10#PROZENT=2.00#. A freely worded sentence in the same place fails validation, and the rule is classified as fatal.
That turns the terms from a display topic into a mandatory field of the outgoing invoice. Anyone planning the move to electronic invoicing looks at this field early, because it originates in the same place as the due date at checkout: in the resolved terms. The article on the e-invoicing mandate and its deadlines places the timeline. In accounting the discount deduction then lands as a posting of its own with a tax correction, and for that the document, the payment and the deduction have to be handed over together; what that path into financial accounting looks like is described in the article on DATEV integration in e-commerce.
The return channel: incoming payments and open items
The integration does not end with the document. Three messages come back from the ERP that should be visible in the customer account: the final due date per invoice, the incoming payment with date and amount, and the status of a discount deduction. Without them the shop shows an order as completed while accounting carries an outstanding claim, and the customer sees no reason to pay earlier. With them the customer account becomes what tips the scales in B2B: a reliable list of open items with dates that a buyer can read without picking up the phone. The technical effort is modest, because the data flows anyway as soon as the payment integration processes the receipt. All that matters is that the shop displays these values and does not recalculate them itself, because a second calculation path sooner or later produces a second truth.
Test cases for net terms and discounts
- A customer with deviating terms sees their own due date at checkout, not the one from the standard terms.
- The date shown at checkout matches the date on the invoice, even when days lie between the order and the invoice.
- Terms with a net period beyond the statutory limit do not appear at checkout but in an approval list.
- The cart deducts no discount amount; the possible deduction sits next to the invoice amount for information.
- A payment within the discount period clears the open item in full, a payment after it leaves a residual claim standing.
- A second discount tier is transferred and shown with its own period instead of being reduced to the first tier.
- With two part invoices, each carries its own due date and discount period, and the customer account shows both separately.
- The electronic invoice contains the discount information in the prescribed pattern and passes validation at the recipient.
- A change of terms in the ERP reaches the shop in the next sync and does not act retroactively on orders already captured.
Net terms without a date are a statement of intent. Only the calculated date next to the amount turns them into terms that purchasing, the shop and accounting all understand the same way.
Sources and legal basis
Related Articles
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.
GPSR: Economic Operator Data From ERP Into Every Listing
The economic operator as a master data object: move manufacturer, responsible person and product identifiers from the ERP into every distance offer.
Daylight Saving Time: Timestamps in ERP Interfaces
On changeover night one hour occurs twice. How timestamps, delta queries and job schedules between shop and ERP stay unambiguous, plus a test plan for October.