Schematron validation for invoice line calculations

[jdiepenmaat]

We've seen some issues with the calculations made in invoice lines, by softwarevendors that generate UBL invoices.

Here's an interesting fragment, that is OK according to the current schematron validations, but is NOT OK according to the rules in the UBL standard.

1. This is what is displayed to the end user on the PDF invoice:

Amount	Description	Price per unit	Total excl tax
157,94 liter	Brandstof	1,03	163,41

2. The UBL representation:

<cac:InvoiceLine>
    <cbc:ID>123456789</cbc:ID>
    <cbc:InvoicedQuantity unitCode="C62" unitCodeListID="UNECERec20">157.94</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="EUR">163.41</cbc:LineExtensionAmount>
    <cac:TaxTotal>
      <cbc:TaxAmount currencyID="EUR">34.32</cbc:TaxAmount>
      <cac:TaxSubtotal>
        <cbc:TaxableAmount currencyID="EUR">163.41</cbc:TaxableAmount>
        <cbc:TaxAmount currencyID="EUR">34.32</cbc:TaxAmount>
        <cac:TaxCategory>
          <cbc:ID schemeAgencyID="6" schemeID="UNCL5305">S</cbc:ID>
          <cbc:Percent>21</cbc:Percent>
          <cac:TaxScheme>
            <cbc:ID schemeAgencyID="6" schemeID="UN/ECE 5153">VAT</cbc:ID>
          </cac:TaxScheme>
        </cac:TaxCategory>
      </cac:TaxSubtotal>
    </cac:TaxTotal>
    <cac:Item>
      <cbc:Description>Brandstof</cbc:Description>
      <cbc:Name>Brandstof</cbc:Name>
      <cac:ClassifiedTaxCategory>
        <cbc:ID schemeID="UN/ECE 5305" schemeAgencyID="6">S</cbc:ID>
        <cbc:Percent>21</cbc:Percent>
        <cac:TaxScheme>
          <cbc:ID schemeAgencyID="6" schemeID="UN/ECE 5153">VAT</cbc:ID>
        </cac:TaxScheme>
      </cac:ClassifiedTaxCategory>
    </cac:Item>
    <cac:Price>
      <cbc:PriceAmount currencyID="EUR">1.03</cbc:PriceAmount>
    </cac:Price>
  </cac:InvoiceLine>

3. What's wrong?

Well, many vendors just use <cbc:LineExtensionAmount currencyID="EUR">163.41</cbc:LineExtensionAmount> and process 163,41 in the bookkeeping software.

We don't, because we want to give the end user the ability to decide if certain amount belongs may not belong in their administration (it's quite good possible that you want to split up a desired amount for private usage).

That's why we display the following in the user interface:

And, as you can see, there is something wrong here because 157,94 x 1,03 isn't equal to 163,41. In this case the vendor should have used amount with 4 decimals instead of two (http://docs.peppol.eu/poacc/billing/3.0/bis/#_unit_price_amount).

Also stated in http://docs.peppol.eu/poacc/billing/3.0/bis/#lineamount-calc.

I would love to see more stricter schematron validations for this.

[jdiepenmaat]

@tjeb here's the issue with amount calculations / validations that I was talking about last week ^

[tjeb]

I have a sneaking suspicion that this scenario is exactly why line-level calculations were removed from the validation... but hopefully they were just removed because rounding in xslt1 was error-prone and they never got re-added since the move to xslt2's xs:decimal.

The latest validation files for PEPPOL BIS v3 do indeed check this again, but CEN/PC434 does not (these rules, are based on that, with the addition of the NL-specific rules). But this may actually be worth porting from peppol, if CEN has a reason not to include it. Especially since some receivers already do check and reject such invoices.