Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-67 | Fatal (error) | /ubl:Invoice | /cn:CreditNote |
| Schematron ID: ibr-084 | Field: ibt-110 and ibt-111 — Invoice total tax amount, and in accounting currency | ||
Classification
Syntax & Integration — a cross-field consistency check on two amounts calculated independently by the source system.
What the Rule Is Checking
Where an invoice declares a tax accounting currency (cbc:TaxCurrencyCode) different from the document currency, two tax totals appear: one in the document currency and one in the accounting currency. The rule requires both to carry the same operational sign — both zero or negative, or both zero or positive.
Where no tax accounting currency is declared, the test short-circuits and the rule passes. It bites only on dual-currency documents.
Why This Rule Exists
In the UAE the accounting currency for tax purposes is AED. An invoice issued in USD, EUR or GBP has to state the tax total twice: once in the transaction currency and once converted to AED at the applicable rate. The two figures are the same economic amount expressed differently, so their signs agree by construction.
A sign mismatch means one of the two was derived wrongly. The most common cause is a credit note where the document-currency total is correctly negative but the AED conversion routine takes an absolute value before applying the rate, or applies the sign convention of the original invoice rather than the credit. What lands with the authority is a document reporting negative output tax in one currency and positive in another, and the reported AED position is the one that feeds the VAT return.
The rule catches at validation what would otherwise appear as an unexplained variance between the transaction ledger and the return.
Standard / Code List
Currency codes on both amounts come from ISO 4217 — see ISO 4217 Currency Codes in UAE E-Invoicing. The accounting currency for UAE tax reporting is AED.
UAE Data Example
PASSES ✓: A credit note in USD with TaxAmount currencyID="USD" of −250.00 and TaxAmount currencyID="AED" of −918.25. Both negative.
PASSES ✓: A standard invoice with 250.00 USD and 918.25 AED. Both positive.
FAILS ✗: A credit note with −250.00 USD and 918.25 AED, produced because the AED conversion runs off the absolute value of the tax base and never picks up the credit indicator.
What Your ERP / IT Team Must Ensure
- Derive the AED tax amount from the signed document-currency amount, rather than from an absolute value with the sign reapplied afterwards.
- Test the conversion routine specifically on credit notes and on invoices with negative lines. The sign error is invisible on standard positive invoices.
- Confirm the currency identifier attribute is written on both tax total amounts. The rule's test selects by
@currencyID, so a missing attribute changes what is being compared. - Check documents where the tax total is zero. Zero passes on either branch, which means a zero-rated dual-currency invoice will not surface a broken conversion routine.
Related Rules
This sits alongside the other total-level arithmetic rules in the series. It checks consistency of sign only, and does not verify that the conversion rate applied was correct — that remains a control you have to operate yourself.