Tolerance of 1 € on BR-S-09

[csautereau]

Calculation Rule BR-S-09 is not as the rule is described in text. A tolerance of 1 € have been added.
It seems to be done on purpose to address some rounding issues where Vat is calculated on line level (and rounded).

However, it is not the rule BR-S-09, which may be changed in the EN16931.
If done, the right tolerance should be 0,01 € (in fact 0,005 if only for VAT calculation on line level, 0,01 is needed for B2C invoices) * (Nbre of lines + nbre Document level charges + Nbre of Document level Allowances).

If we enter in tolerances to address VAT calculation on line Level + B2C with prices including VAT, there are other rules which need modifications.

I can provide the full set which has been done on EXTENDED profile for CII if needed.

BR-S-09 : No tolerance
“The VAT category tax amount (BT-117) in a VAT breakdown (BG-23) where VAT category code (BT-118) is "Standard rated" shall equal the VAT category taxable amount (BT-116) multiplied by the VAT category rate (BT-119).”

And in CII
“ [BR-S-09]-The VAT category tax amount (BT-117) in a VAT breakdown (BG-23) where VAT category code (BT-118) is "Standard rated" shall equal the VAT category taxable amount (BT-116) multiplied by the VAT category rate (BT-119).

in UBL
[BR-S-09]-The VAT category tax amount (BT-117) in a VAT breakdown (BG-23) where VAT category code (BT-118) is "Standard rated" shall equal the VAT category taxable amount (BT-116) multiplied by the VAT category rate (BT-119).

[oriol]

The slack was added in version 1.3.7 in UBL and in 1.3.8 in CII.
In order to avoid going back and forth on this, I think it is better to have the discussion in the CEN TC 434 and conclude on whether adding or not the slack in the EN 16931 ruleset

[phax]

@csautereau also please note:

• The slack is 1 and not 1€ - it's currency independent and
• The slack is not defined in EN but currently only in the validation artefacts, because we miss a unified algorithm to calculate invoicing subtotals and totals

[SimonsPaul]

A slack is not foreseen in the current version of the EN16931-1. It was added in the schematron rules for practical reasons to deal with small rounding issues due to the use of different rounding mechanisms in the tools and/or countries. The Revised EN16931-1 will allow a slack to deal with these small rounding issues. The schematron will be brought in line with the rules accordingly.

[AndreasPvd]

When discussing this please do not forget that the EN is semantics only and should stay absolutely tool and syntax agnostic. Having implemented a slack on the schematron has some more or less good reasons. But tool-problems should never influence the semantics. If you want to add some slack rules on the documentation side it must be placed in CEN/TS 16931-3-1 as this is bridging the semantics to the syntax part and was always intended as the umbrella document for all syntax related rules that have impact on every applied syntax. Please take this with you in the TC434 discussions.

[csautereau]

Yes, this is my point. Do we consider that the validation tool must but the exact implementation of the EN16931-1 semantic business rules, or do we consider that the validation tool can add some tolerances (which normally are only allowed on EXTENDED profiles).
At least it should be documented, and certainly discussed within TC434 (WG 1 if a first tolerance has to be added on EN16931 and WG5 if calculation rounding is studied in a larger scale) to get to a kind of consensus. My point was also that if tolerance has to be added, it would be better to have one which is mathematically right instead of deciding that 1 should be enough.

[SimonsPaul]

Rounding issues are not only related to schematron tools nore to development tools. When a tolerance is implemented at semantic level, it is the best way to guarantee coherence between different syntaxes. Let us not forget that the EN16931-1 is more and more used/mandated in other scenarios than B2G e.g. B2B. The EH Directive 2014/55 is only applicable for B2G. I refer to the ViDA project and National formats that allow/mandate other syntaxes than the 2 withheld in EN16931-2 (as long as they are convertible whatever that means).

[SimonsPaul]

Hi Cyrille

Indeed. The Revision will contain a slack in the EN16931-1 itself to avoid discussions and adding slacks in schematrons not in line with the EN16931-1 itself. So there will be no need to "Extend" in WG5. Be aware however that the slack does not cater to allow deviations due to prices inclusive VAT or VAT at line level or amounts at line level with more than 2 decimals that are rounded at 2 (although to a certain extend they will validate as inside the slack of course).

[csautereau]

Hi Paul

YES, the EN, all the EN, only the EN, for EN profile.
Regarding Unit price including VAT, I know that it is not in the EN. However, as some business are more focused on B2C, the need to issue a B2B invoice based on this can happen. But only on EXTENDED profile ...

[SimonsPaul]

Keep in mind that we are about to publish the TS16931-8 e-Receipt/Simplified Invoice that has as much as possible the same semantics but allow for e.g. those B2C requirements. To be discussed if this is not a better way than extending the EN itself. :)

[raphaelm]

Be aware however that the slack does not cater to allow deviations due to prices inclusive VAT or VAT at line level or amounts at line level with more than 2 decimals that are rounded at 2 (although to a certain extend they will validate as inside the slack of course).

What is the slack intended for, then, and what is the plan for people who are in a conflicting situation then?

For example a book dealer in Germany needs to

• issue an EN16931 invoice starting 2027 by law when selling B2B
• have book prices calculated vat-inclusive since there is a law on fixed book prices (Buchpreisbindung) that assumes vat-inclusive prices
  How do you recommend solving that deadlock?

[csautereau]

Here comes real life ! Thanks for the example.
another one : a bundle book +toy, book 10% VAT, toy 20% vat, but this is a unique article with price Vat included for the bundle.

[oriol]

I really think this is not the place for this discussion. You should join the TC434 and discuss it there.

[phax]

@raphaelm That's where BT-114 Rounding Amount kicks in, if there is a difference between calculated gross amount and effective gross amount,

[SimonsPaul]

Thank you @oriol. I agree with your wise words.

Let me add that Germany and France approved the EN16931-1 long ago. Moreover Germany approved the internal ballot related to changes for the Revision while France abstained. Meaning France agrees with what is agreed by the other countries that expressed a vote.

@raphaelm and @csautereau: I suggest you talk to the people with voting rights in your country or as Oriol is suggesting, participate in the meetings yourself.

In the meantime, please read the EN16931-1. It does not cover all possible scenarios and it was not meant to cover all. So I am sure you can give more examples that do not fit in. The EN16931-1 is a core invoice model. For scenarios that are not covered, there is the extension mechanism. If you need it for your scenarios, join the meetings in WG5 and discuss.

[csautereau]

As you said this is not the place. Just to finish, I fully agree that the EN16931 was not designed to address all Bcase but only the more standard ones. And I participated to the vote for this in 2017. What is strange is to consider that EN16931 should now be used as is for 100% of situation for ViDA or sometimes on domestic level, as it was not designed for this.
EN Evolution will not solve this and I do not blame anyone for this. I think that the solution is around extensions, which is not the subject of WG1 if I have well understood.
I am finished. Full stop. Kind Regards.