In short and in plain language
A shop often works out the tax for each line on its own. The ERP often works it out once for the whole total. Both round at a different point. That is why one cent can go missing.
From 2027, many firms will get their bills as a data file. A program can check this file. It does the sums again to see if tax and total match.
The rule for this is called BR-CO-17. The tax is worked out per tax rate on the total. Then it is rounded to two places after the point.
It helps if only one system does the sums. The others just take over the numbers. Tests with many small lines show early if all is right. We help you make the change.
A business customer orders twelve units of an item at 19.90 euros each in the shop, plus two further items at 7.49 and 4.99 euros. They pay 251.28 euros in advance, and two days later the ERP system produces an invoice for 251.27 euros. The incoming payment does not match the open item, accounting writes off one cent, and the next order starts the same cycle again. With e-invoicing, that annoying cent becomes a question of rules: the European standard EN 16931 defines how line amounts, VAT and totals relate to each other, and validation software recalculates this automatically. For supplies from 1 January 2027, the transition rule for paper and PDF invoices only applies to businesses whose total turnover in the previous year was no more than 800,000 euros (Section 27(38) UStG). Anyone above that needs e-invoices for invoices to domestic business customers, unless they bill through an EDI procedure. This article shows where the cent differences come from, what the EN 16931 rule BR-CO-17 requires, when VAT is calculated per line and when per rate on the total, how many decimals prices in the ERP need, how discounts are split across several VAT rates and which test cases secure your calculation path before the deadline.
Key takeaways
- For supplies from 1 January 2027, the paper and PDF transition rule only applies up to 800,000 euros of prior-year turnover (Section 27(38) UStG). Above that, invoices to domestic business customers generally go out as EN 16931 e-invoices.
- The EN 16931 rule BR-CO-17 calculates VAT per rate on the total of the net amounts and rounds to two decimals (Peppol BIS Billing 3.0). Rounding per line and adding up misses by one cent for 12 × 19.90, 7.49 and 4.99 euros.
- With gross prices, not every final amount has a matching net total: at 19 percent there is none for 249.99 euros (Section 12(1) UStG). Net prices with VAT on the total therefore suit business customers better.
- Keep net prices in the ERP with four decimals and amounts with two: 12 × 16.72 euros gives 200.64 euros, 12 × 16.7227 euros gives 200.67 euros. The BR-DEC decimal rules cover amounts, not the item net price BT-146 (Peppol BIS Billing 3.0).
- A voucher on goods at 19 and 7 percent becomes two allowance lines, because every document-level allowance carries one VAT category and one VAT rate (Peppol BIS Billing 3.0). A fixed rule gives the leftover cent to the largest share.
- Exactly one system calculates VAT and totals, the others take the amounts over unchanged. Test cases with rounding limits, 40 small lines and mixed rates check the path; the validation report is kept (BMF letter of 15 October 2025).
Where the cent between shop and invoice comes from
Take the basket from the introduction, all items at the standard VAT rate of 19 percent (Section 12(1) UStG) and all prices shown gross. The shop calculates the way that feels natural in consumer retail: it extracts the VAT from each line amount, rounds per line and adds up. The 238.80 euros for the twelve units contain 38.13 euros of VAT, 7.49 euros contain 1.20 euros and 4.99 euros contain 0.80 euros. Together that is 40.13 euros of VAT, 211.15 euros net and 251.28 euros gross. The customer sees this amount in the checkout, and this is the amount they pay.
| Amounts in euros | Shop | ERP | E-invoice |
|---|---|---|---|
| Starting point | gross price per unit | net price with four decimals | amounts from the ERP |
| Line with 12 units | 238.80 gross, including 38.13 VAT | 12 × 16.7227 = 200.67 net | line amount 200.67 (BT-131) |
| Lines 2 and 3 | 7.49 and 4.99 gross, including 1.20 and 0.80 VAT | 6.29 and 4.19 net | 6.29 and 4.19 (BT-131) |
| VAT | rounded per line, total 40.13 | 211.15 × 19% = 40.12 | 40.12 (BT-117) according to rule BR-CO-17 |
| Gross | 251.28 | 251.27 | 251.27 (BT-112) |
The ERP system takes over the net amounts of the lines, 200.67, 6.29 and 4.19 euros, and calculates the VAT once on the total: 211.15 euros times 19 percent is 40.1185 euros, rounded 40.12 euros. The invoice therefore comes to 251.27 euros. This is exactly what the e-invoice requires: the VAT amount per rate is the taxable amount per rate times the rate divided by 100, rounded to two decimals (Peppol BIS Billing 3.0). The customer transferred 251.28 euros, the invoice asks for 251.27 euros, and accounts receivable shows an overpayment of one cent.
Both calculation paths are consistent in themselves. The difference arises because three roundings per line do not add up to the same result as one rounding on the total. Each individual rounding shifts the result by at most half a cent; over three lines that adds up to one cent here, over many lines to several. Anyone who calculates 40 separate lines at 0.99 euros gross each, line by line, arrives at 6.40 euros of VAT and 33.20 euros net. Calculated on the total of the net amounts, the VAT is 6.31 euros, and the invoice ends at 39.51 instead of 39.60 euros. That is nine cents nobody ordered.
What EN 16931 prescribes
The German VAT Act requires a structured format for e-invoices that complies with the European standard on electronic invoicing, or an agreed format from which the details can be transferred correctly and completely into a compliant or interoperable format (Section 14(1) UStG). The XRechnung standard complies with the EN 16931 series (BMF letter of 15 October 2025). The standard comes with business rules that define how the amounts on an invoice relate to each other. Peppol BIS Billing 3.0, a core invoice usage specification of EN 16931, documents the wording and the test expressions of these rules in openly accessible form (Peppol BIS Billing 3.0). Which formats are permitted in Germany is covered in our article on the 2027 e-invoicing mandate and the ERP shop interface. For rounding, these rules matter most (Peppol BIS Billing 3.0):
- BR-CO-10: The sum of invoice line net amounts (BT-106) is the sum of all line amounts (BT-131).
- BR-CO-13: The invoice total without VAT (BT-109) is this sum minus document-level allowances plus document-level charges.
- BR-S-08: For each VAT rate, the taxable amount (BT-116) is the sum of the lines at this rate, plus charges and minus allowances at the same rate.
- BR-CO-17: The VAT amount per rate (BT-117) is the taxable amount times the rate divided by 100, rounded to two decimals.
- BR-CO-14 and BR-CO-15: The total VAT (BT-110) is the sum of the VAT amounts per rate, the gross total (BT-112) is the net total plus total VAT.
- BR-DEC: Amounts such as the line amount, the taxable amount and the VAT amount per rate have at most two decimals.
What matters is what this chain lacks: a VAT amount per line. Each line carries its VAT category and, except for supplies not subject to VAT, its VAT rate (Peppol BIS Billing 3.0). The VAT amount only arises in the breakdown per combination of category and rate. This fits the German VAT Act, which requires the invoice to show the consideration broken down by tax rates (Section 14(4) no. 7 UStG) and the applicable tax rate together with the tax amount on the consideration (Section 14(4) no. 8 UStG). In a hybrid format of PDF and XML, the data of the structured part takes precedence over the image file in case of deviations (BMF letter of 15 October 2025). A VAT column per line in the PDF therefore does not help if the XML calculates differently.
What the test expression allows
VAT per line or on the total
At its core, there are two calculation paths. In the first, VAT is calculated per line, rounded and then added up. In the second, the net amounts of all lines with the same VAT rate are added up, and VAT arises once on this total. The first path is the obvious one when prices are shown gross: anyone offering goods to consumers has to state the total prices (Section 3 PAngV), and every line in the basket is then already a final price. The second path is the one the e-invoice recalculates.
| Aspect | VAT per line | VAT per rate on the total |
|---|---|---|
| Rounding | once per line | once per VAT rate |
| Fixed point | gross amount of each line | net amount of each line |
| Typical for | consumer shops with gross prices | B2B shops and ERP with net prices |
| Many lines | rounding remainders add up | one rounding remainder per VAT rate |
| Relation to the e-invoice | deviates from BR-CO-17 as soon as the remainders do not cancel out | matches the calculation path of BR-CO-17 |
| Effect on reconciliation | amount paid and invoice amount can differ by cents | shop and invoice show the same amount if both calculate this way |
For business customers, there is therefore a lot to be said for switching the shop to net prices and VAT on the total. In Shopware, each customer group can be set individually to show and calculate prices gross or net (Shopware documentation). If you run a customer group for business customers, you can calculate net there and keep gross prices for consumers. Which group a customer gets belongs in the ERP customer master, not in a setting someone maintains by hand in the shop. How this interacts with tax determination in the B2B shop is covered in a separate article.
Gross prices: calculating back from the final amount
If gross prices stay, for example because consumers and business customers order in the same shop, the final amount paid is the fixed point. The leading system then calculates the VAT per rate back from the gross amount, not per line. In the example, 251.28 euros times 19 divided by 119 gives 40.12 euros of VAT after rounding and 211.16 euros net (Section 12(1) UStG). The cross-check under BR-CO-17 works: 211.16 euros times 19 percent is 40.1204 euros, rounded 40.12 euros. For the lines to reach 211.16 euros, one line receives the leftover cent according to a fixed rule, for example the line with the highest amount. Peppol checks the line amount against quantity times price with a leeway of 0.02 (Peppol BIS Billing 3.0); a distributed leftover cent stays within it.
This back calculation cannot work out in every case. With two decimals, some gross amounts at 19 percent (Section 12(1) UStG) cannot be represented as a net amount plus rounded VAT at all. One example is 249.99 euros: 210.07 euros net gives 249.98 euros, 210.08 euros net gives 250.00 euros. For the amount in between there is no net amount for which BR-CO-17 works out without deviation. Such gaps occur every time the rounded VAT jumps by one cent. These cases need a decision before the first one occurs: either business customers get net prices, or you agree with your tax advisor how the cent is treated and check whether your recipients' validation accepts it.
VAT shown too high is VAT owed
There is some relief for small amounts. Invoices whose total does not exceed 250 euros may be transmitted as a so-called other invoice, for example as a PDF (Section 33 UStDV). This does not apply to distance sales, intra-community supplies and supplies for which the recipient owes the tax (Section 33 UStDV). If you have many small orders from business customers, you do not have to solve the rounding question in the structured format for them. The distinction must then be built firmly into the system, though, because a basket above 250 euros falls under the obligation again.
More decimals in the ERP: a price is not an amount
The second source of cent differences is prices that are rounded too early. The e-invoice distinguishes between the net price of an item (BT-146) and the net amount of a line (BT-131). The two-decimal limit applies to the line amount, the taxable amount and the VAT amount per rate (Peppol BIS Billing 3.0); none of the BR-DEC decimal rules covers the item net price. An ERP can therefore keep and transfer the net price with four decimals, and it should do so when gross prices are the starting point.
In the example, one unit costs 19.90 euros gross, which is about 16.72269 euros net. Stored with two decimals, this becomes 16.72 euros, and twelve units come to 200.64 instead of 200.67 euros. The whole invoice then lands at 251.23 euros, five cents below the amount in the shop. With four decimals, 16.7227 euros, the same quantity gives 200.6724 euros and 200.67 euros after rounding. The difference comes solely from how the price is stored and grows with the quantity. Peppol describes the calculation explicitly: quantity times price per price base quantity is rounded to two decimals, and line allowances and charges are rounded separately (Peppol BIS Billing 3.0).
For very small unit prices, the price base quantity (BT-149) helps. A screw at 0.0123 euros net can be priced at 12.30 euros per 1,000 units; the line amount then follows from price divided by base quantity times quantity (Peppol BIS Billing 3.0). In Peppol, the unit of the base quantity must be the same as that of the invoiced quantity (Peppol BIS Billing 3.0). How units and pack sizes get from the ERP into the shop cleanly is covered in our article on units of measure and pack sizes. It also explains why amounts belong in a decimal type rather than a floating-point number.
The shop has its own settings, too. In Shopware, each currency defines how prices in the basket and in the subtotals are rounded, the grand total is set separately, and a separate switch decides whether the rounding of the lines also applies to net customers (Shopware documentation). These settings belong in the same calculation rule as those of the ERP. If they differ, both systems calculate correctly and still differently. The cause then lies in the price synchronization or in the data mapping between ERP and shop.
Discounts at line or document level
Allowances are the third source. EN 16931 knows two places for them. A line allowance (BT-136) reduces the line amount and flows into the sum of the lines. A document-level allowance (BT-92) sits next to the lines and reduces the taxable amount of its VAT rate. Every document-level allowance and charge carries a VAT category and, except for supplies not subject to VAT, a VAT rate (Peppol BIS Billing 3.0). A basket voucher on goods at 19 and 7 percent (Section 12 UStG) therefore becomes two allowance lines, one per rate.
Which place is right depends on where the shop calculates the discount. If it calculates a percentage discount per line, the allowance belongs on the line, and each line is rounded individually. If it calculates a voucher on the basket, it belongs at document level, and then a fixed split is needed. For percentage allowances, Peppol checks that the amount equals the base times the percentage divided by 100, with a leeway of 0.02 (Peppol BIS Billing 3.0). How early payment discounts are shown on the invoice is a separate question, covered in our article on payment terms and early payment discounts in the B2B checkout. A basket voucher needs a sequence that all systems carry out the same way:
- Determine the shares: split the voucher in proportion to the goods value per VAT rate, on the basis your tax advisor sets for reducing the consideration.
- Round each share: round every share on its own to two decimals.
- Assign the leftover cent: add the difference between the rounded shares and the voucher amount to the largest share, so the allowance lines add up exactly to the voucher.
- One line per rate: transfer each share as a separate document-level allowance with VAT category and VAT rate.
- Pass on unchanged: ERP and invoicing module take over the split instead of recalculating it.
Shipping costs work the same way in the opposite direction. If they are transferred as a document-level charge, they also need a VAT category and a VAT rate. How shipping costs are treated for VAT on a basket with different VAT rates is a question for your tax advisor; technically, it again results in a split with a fixed rounding rule. What matters is that shop and ERP apply the same rule. Otherwise the cent arises not in the VAT but already in the taxable amount.
One leading system for the calculation
All the cases so far share one cause: two systems calculate the same transaction, each according to its own logic. The solution is therefore organizational, not mathematical. One system calculates line amounts, allowances, VAT per rate and totals, all others take over the amounts and check them without recalculating. Which system issues the invoice is a preliminary question here, covered in our article on whether the invoice comes from the shop or the ERP. The calculation does not have to live in the same system as the invoice number, but it must clearly belong to one system.
| Option | How it works | Prerequisite |
|---|---|---|
| Shop calculates, ERP takes over | The shop calculates the basket along the calculation path of the e-invoice; the ERP takes over amounts and VAT unchanged. | The ERP accepts transferred VAT amounts and does not recalculate. |
| ERP calculates, shop displays | The checkout requests prices and totals from the ERP or the middleware and displays the result. | Fast price lookup and a fallback when the ERP does not respond. |
| Invoicing module recalculates | Invoice creation recalculates everything from quantities and prices. | Only viable if all systems use exactly the same calculation rule; otherwise a source of differences. |
For the handover, this means: the interface transfers not only quantities and prices but also the calculated amounts, that is line amount, allowances and charges per rate, taxable amount and VAT per rate, and the totals. The receiver checks the total rules itself and puts a transaction with a deviation on an error list instead of silently correcting it. This check fits into a middleware between the shop and the ERP system. If an order changes after the handover, the same applies to the changed amounts; how to follow up cleanly is shown in our article on order changes after the ERP export.
Amount due, rounding amount and open items
If the cent still occurs, it ends up in payment reconciliation. The customer paid the amount from the checkout, the invoice states a different one. The open item remains with one cent or is booked as an overpayment. With a few orders a month this is a nuisance, with thousands it becomes a task of its own. How payments are matched automatically is described in our article on payment reconciliation. A tolerance rule there only shifts the problem into accounting, though, and through the DATEV integration every write-off generally reaches the tax advisor's office as a separate booking entry.
The e-invoice has its own field for a rounding amount (BT-114). The amount due for payment (BT-115) is the gross total minus amounts already paid plus the rounding amount (Peppol BIS Billing 3.0). The field is meant for rounding the amount payable; Peppol gives the example of 999.81 rounded to 1,000 with a rounding amount of 0.19 (Peppol BIS Billing 3.0). The rounding amount does not change VAT or totals. Whether it may bridge a cent between checkout and invoice is not a technical question but one for your tax advisor. It is cleaner if the cent does not arise in the first place.
What validation reports
The Federal Ministry of Finance distinguishes between format errors and business rule errors in e-invoices. A business rule error exists, for example, when details contradict each other; as an example, the letter names a tax amount that does not match the stated tax rate arithmetically (BMF letter of 15 October 2025). If an invoice violates the mandatory details under Section 14(4) UStG, it is not a proper invoice, and such content errors can show up during validation as a breach of a business rule (BMF letter of 15 October 2025).
For the recipient, the letter states that validation supports checking the invoice but does not replace it. A business exercising the due care of a prudent merchant can rely on the technical result of a suitable validation application, and keeping the validation report is recommended as evidence (BMF letter of 15 October 2025). Your business customer can therefore check your invoice automatically and rely on the result. For outgoing invoices, this means: every e-invoice is validated before it is sent, and the report is filed with the invoice. An additional, strict check of BR-CO-17 without leeway is worthwhile. It shows where your calculation deviates from the rule description before a customer with a stricter check finds out.
Test cases with edge values
Rounding errors do not show up on average, but at the edges. Practically any calculation path passes a test with a single line of 100 euros net. The following cases belong in every acceptance test of a shop-ERP integration that produces e-invoices, and in every regression run after an update of the shop, the ERP or the invoicing module:
- Many small lines: 40 separate lines at 0.99 euros gross each. Calculated per line they give 6.40 euros of VAT, on the total of the net amounts 6.31 euros.
- Quantity times an odd price: 12 units at 19.90 euros gross, once with the net price at two and once at four decimals.
- Half a cent: 1.50 euros net at 19 percent (Section 12(1) UStG) gives 0.285 euros of VAT, 0.29 euros with commercial rounding and 0.28 euros when rounding to the even digit. All systems need the same rounding mode.
- Mixed VAT rates: goods at 19 and 7 percent in one basket (Section 12 UStG), plus shipping costs and a voucher on the whole basket.
- Percentage discount: the same discount once per line and once at document level, with lines whose discount ends on half a cent.
- Partial credit note: take back one line of an invoice and check whether invoice minus credit note gives exactly the remaining amount.
- Zero rate: lines at 0 percent next to taxable ones; at a rate of zero, the rounded VAT amount must be zero (Peppol BIS Billing 3.0).
- Price base quantity: items priced per 100 or per 1,000 units with a quantity that is not a multiple of the base quantity.
- Gross amount without a net partner: a basket of 249.99 euros gross at 19 percent (Section 12(1) UStG) to test the rule for amounts that cannot be represented.
Every test case has an expected result to the cent, calculated beforehand by hand or in a spreadsheet, not by the system itself. The cases run in a test environment with its own test data and not against live data; how to set one up is described in our article on test environments for ERP interfaces. Partial deliveries add further cases, listed in our article on partial deliveries and part invoices.
Five steps to one shared calculation path
Record the calculation paths
For shop, ERP, invoicing module and accounting, write down where rounding happens, with how many decimals prices and amounts are stored and which rounding mode applies. Collect transactions with cent differences from payment reconciliation.
Define the calculation path
Decide per customer group: net prices with VAT on the total for business customers, back calculation from the gross amount where gross prices stay. Record the leading system and the rule for leftover cents in writing and agree them with your tax advisor.
Adapt the data model
Net prices with four decimals, amounts with two, a decimal type instead of floating point, a price base quantity for small unit prices and a fixed split of vouchers and shipping costs per VAT rate.
Hand over without recalculation
The interface transfers the calculated amounts per line and per VAT rate. Receivers check the total rules and report deviations to an error list instead of recalculating.
Test and validate
Run the test cases with edge values, validate every outgoing e-invoice, additionally check BR-CO-17 without leeway and file the validation report with the invoice.
For shop, ERP, invoicing module and accounting, write down where rounding happens, with how many decimals prices and amounts are stored and which rounding mode applies. Collect transactions with cent differences from payment reconciliation.
Decide per customer group: net prices with VAT on the total for business customers, back calculation from the gross amount where gross prices stay. Record the leading system and the rule for leftover cents in writing and agree them with your tax advisor.
Net prices with four decimals, amounts with two, a decimal type instead of floating point, a price base quantity for small unit prices and a fixed split of vouchers and shipping costs per VAT rate.
The interface transfers the calculated amounts per line and per VAT rate. Receivers check the total rules and report deviations to an error list instead of recalculating.
Run the test cases with edge values, validate every outgoing e-invoice, additionally check BR-CO-17 without leeway and file the validation report with the invoice.
Only a few weeks remain until 1 January 2027 for the changeover. Anyone who does not align the calculation paths beforehand often only notices the differences in payment reconciliation at the end of the month. Our work around e-invoicing starts exactly here: defining the calculation path, adapting the interface, running the test cases and validating outgoing invoices. For your own checking and calculation services between the systems, API development is the right starting point.
One calculation path, one figure
Related Articles
Order changed after the ERP export: syncing it cleanly
Address, quantity or cancellation after the ERP export: how shop and ERP sync order changes with a picking lock, a change event, line matching and an audit log.
Black Week order peak: preparing your ERP interface
Black Week 2026: prepare the order flow between shop and ERP – measure the backlog, move night jobs, add a queue with alerts, freeze changes, define a fallback.
Invoice from shop or ERP? Setting the leading system
Shop or ERP: which system issues the invoice and assigns the number? A decision matrix for partial delivery, cancellations, marketplaces and e-invoicing.