Automatic Rounding Lines

When an inbound e-document (invoice or purchase order) is received, the total amount stated in the XML may not exactly equal the sum of the individual document lines after VAT calculations in Business Central. This is a natural consequence of how BC applies rounding precision per line — each line is rounded independently, and the cumulative effect of many small rounding differences can produce a total that diverges from the supplier’s stated total by a few cents or fractions of a currency unit.

Why this matters

This is especially common in transactions involving many line items or high unit quantities. The sending ERP system and Business Central may apply VAT rounding at different stages or with different precision rules, producing slightly different totals from the same underlying data. For companies processing hundreds of invoices with dozens of lines each — such as wholesale, manufacturing, or retail supply chains — these small mismatches would otherwise require manual correction on every affected document before it can be posted.

The automatic rounding line feature resolves this by inserting a small G/L Account adjustment line so that the BC document total matches the supplier’s stated total exactly, which is a prerequisite for successful posting. Without it, every rounding mismatch would block the posting pipeline and require manual intervention.

Setup

Location: Purchases & Payables Setup → eMessaging tab

Field	Description
Rounding Line Account No.	The G/L Account to post the rounding difference to. Required — without this, no rounding line will ever be created.
Rounding Threshold	Maximum allowed rounding difference. If the difference exceeds this value the system throws an error instead of silently adding a line. Set to 0 to disable threshold checking.
Ask to Add Rounding Line	When enabled, prompts the user interactively to confirm before adding the rounding line (manual posting only — has no effect in autoprocess).
Match Purchase Doc. against Inbound Doc.	When enabled, validates that the BC document total matches the e-document total before posting is allowed. Works together with the rounding check at post time.

How the difference is calculated

When a document is imported, eMessaging compares two values:

• Supplier’s stated total — the tax-inclusive total amount from the inbound e-document (the TaxInclusiveAmount in the PEPPOL XML). If the document includes a payable rounding amount, that is factored in automatically.
• Business Central’s calculated total — the sum of Amount Including VAT across all purchase lines after BC has applied its own VAT calculations and rounding.

The difference between these two values is the rounding discrepancy. If the difference is smaller than the currency’s Amount Rounding Precision, it is treated as zero and no rounding line is created.

When the rounding line is created

There are two points in the process where the system attempts to insert a rounding line:

At document creation (import)

When an inbound e-document is first processed and purchase lines are created, the rounding check runs immediately after all lines are inserted. If the totals don’t reconcile, the rounding line is added before the document is ever sent for approval or released.

At document update

When an existing purchase order is reconciled against an updated inbound document, the rounding check runs again after amounts are updated. This handles the case where the document already existed and its amounts were revised.

In both cases the logic is the same: if a Rounding Line Account No. is configured, the difference is non-zero, and the difference is within the threshold, a new purchase line is inserted with:

Field	Value
Type	G/L Account
No.	The configured Rounding Line Account
Quantity	1
Direct Unit Cost	The exact difference amount (positive or negative)
Dimensions	Inherited from the purchase header

Interaction with auto-posting

The rounding feature is tightly coupled with auto-posting.

At posting time, the subscriber PurchPost_OnBeforePostPurchaseDoc fires on Codeunit “Purch.-Post” for any document that originated from an inbound e-document (RSMSTA From Inbound e-Document or RSMSTA Autoprocessed flags). If Match Purchase Doc. against Inbound Doc. is enabled and the document is being invoiced, CheckForRounding is called.

The behaviour depends on context:

Context	Behaviour if difference exists
Interactive (user posting manually)	User is prompted: “Total Amount Including VAT X is not equal to eInvoice Total Amount Including VAT Y — do you want to continue?” If Ask to Add Rounding Line is on and the difference exceeds the threshold, a second prompt asks if they want to add the rounding line.
Headless / Autoprocessed (job queue or Auto-Post Approved Invoices)	No dialog is shown. If a difference still exists, posting fails with an error and the e-document status is set to Error.

This means the auto-posting pipeline has a hard dependency on the rounding line being in place before posting is attempted:

flowchart TD
    A["Inbound document received"] --> B["Lines created →\nRounding line added if difference exists"]
    B --> C["Document sent for approval\n(if applicable)"]
    C --> D["Approved → Released →\nAuto-Post fires"]
    D --> E{"Difference = 0?"}
    E -- "Yes (rounding line in place)" --> F["Post succeeds\nStatus: Processed"]
    E -- "No (rounding line missing\nor amounts changed)" --> G["Error\nStatus: Error"]

Practical implication: If auto-posting is failing with a total amount mismatch error, the most common cause is that Rounding Line Account No. was not configured at the time the document was imported, so no rounding line was ever inserted. The document needs to be corrected manually (add the rounding line) before it can be re-posted.

Threshold behaviour and error handling

The Rounding Threshold setting protects against large discrepancies being silently absorbed as “rounding”. A difference that exceeds the threshold is treated as a real data problem, not a rounding issue.

Scenario	Outcome
Difference = 0	Nothing created, no check
0 < Difference ≤ Threshold	Rounding line created automatically
Difference > Threshold	Error (see below)
Rounding Line Acc. No. not set	Feature is entirely skipped — no rounding line is ever created regardless of threshold

When the difference exceeds the threshold, the error message is intentionally diagnostic:

“The rounding difference X exceeds the allowed threshold of Y. This usually means that E-document lines are being posted to G/L or Item with different VAT%.”

A difference larger than expected rounding typically indicates a VAT rate mismatch between the inbound document lines and the posting setup in BC, not a rounding issue.

Related pages

• Auto-Post Approved Invoices — how auto-posting depends on rounding lines being in place
• Auto Processing — the full auto-processing pipeline
• Posting Documents — manual and auto posting
• Purchases & Payables Setup — where rounding settings are configured