Representing cash discounts (Skonto) correctly in e-invoices

An early-payment discount — Skonto in German-speaking markets — looks trivial on a paper invoice: “2% within 10 days, otherwise net 30”. A human reads it, does the mental arithmetic, and pays the reduced amount if they are quick. In a structured e-invoice the same sentence needs real care, because EN 16931 has no dedicated field for a discount that only applies if the buyer pays early.

Why there is no “Skonto field”

The EN 16931 data model describes what is owed now: a definite total, a definite VAT breakdown, definite line items. An early-payment discount is none of those — it is conditional on an event (payment timing) that has not happened yet at the moment of issue. Forcing that conditional amount into a field meant for a definite value is the root of nearly every Skonto bug.

The payment terms carry the discount (BT-20)

The established route is the payment terms text, BT-20. XRechnung defines a machine-readable convention for it, so the buyer’s software can parse the percentage, the deadline and — optionally — the base amount. Each rule sits on its own line:

#SKONTO#TAGE=10#PROZENT=2.00#
#SKONTO#TAGE=30#PROZENT=1.00#

You can express several tiers this way (2% within 10 days, 1% within 30), and pin the base with #SKONTO#TAGE=14#PROZENT=3.00#BASISBETRAG=1000.00# when the discount applies only to part of the invoice. Free-text terms still work for humans, but only the structured form is reliably machine-readable across receivers.

The document total stays whole

The key technical point: the discount is not subtracted from the document total. The invoice is transmitted over the full amount, and the payable total (BT-115) equals that full amount. The reduced figure becomes relevant only if and when the buyer actually pays inside the window. The e-invoice states the obligation; the discount is an option the buyer may exercise later.

Don’t model it as an allowance (BG-20)

The most common implementation mistake is to encode Skonto as a document-level allowance, BG-20. In the data model an allowance reduces the payable amount unconditionally and feeds into the totals and the VAT breakdown (BG-23) — which is exactly what a conditional early-payment discount must not do at issue time. Mix the two and you get two failures at once: the arithmetic business rules (BR-CO-…) reject the document because the totals no longer reconcile, and even if they did, you would be transmitting a VAT base that is wrong until the discount is actually taken.

The VAT angle

VAT follows the same logic. At issue, VAT is calculated on the full amount. Only when the discount is genuinely taken does the taxable base change — handled as a subsequent correction (in Germany, § 17 UStG), not as a reduction baked into the original document. Encoding the discounted VAT up front is both wrong and a reliable validation failure.

In short

• Put Skonto in the payment terms (BT-20), ideally in the structured #SKONTO# form.
• Keep the document total and VAT at the full amount.
• Never model it as a BG-20 allowance.

eunormia recalculates every total server-side and rejects an invoice whose totals do not add up, rather than silently correcting them. That keeps Skonto a deliberate modelling decision in the payment terms — not an accident that slips through the gate and lands on a receiver’s desk as a document that does not reconcile.