A field-by-field guide for totals mismatches, payable amount drift, and rounding side effects in e-invoice exports.
Broken totals usually come from a late charge, a duplicated rounding line, or a manual edit that left the ERP totals and exported totals out of sync.
That is why validators often report a totals rule code instead of the business action that caused it.
If the payable amount is higher than the tax-inclusive total, inspect prepayments, cash rounding, and settlement adjustments first.
If the tax-inclusive amount does not equal tax-exclusive plus tax, recompute the invoice from the source instead of patching the XML.
Cash rounding can be valid inside the ERP and still break a stricter e-invoice rule set if the exported totals no longer reconcile.
The cleanest fix is to adjust the invoice logic in the ERP and create a fresh export.
If you hit BR-CO-10, the invoice totals do not reconcile. This page translates the rule into practical bookkeeping and ERP checks.
Open issue pageRounding logic that looks harmless in the ERP can still produce totals that fail e-invoice validation. This page isolates the most common pattern.
Open issue pageThis is a precise invoice arithmetic failure, not vague validator fog. The page shows what causes it and which ERP fields to inspect first.
Open issue pageBelgian zero-VAT or exempt invoices can still fail Peppol export when the tax category and exemption metadata do not line up with what the connector expects.
Open issue pageOdoo may let you combine Belgian VAT and roerende voorheffing logic on one line, but the Peppol UBL export can still fail when that tax structure does not map cleanly to one invoice item.
Open issue pageGuides are useful when the pattern is familiar. When the latest failure still feels fuzzy, run the analyzer with the exact provider message or XML so you can separate routing, profile, and provider-state problems.