Gross price invoices

[svanteschubert]

Background

Gross price invoicing was possible with ZUGFeRD 1.0, but is no longer possible from ZUGFeRD 2.0 comfort (standard-compliant).

Objective

The existing status quo must be maintained in the applications (company-specific) (gross price invoices). ZUGFeRD 1.0 is to be replaced in the medium term

Challenges

View component based on gross prices standard-compliant XML

Open Questions

How are rounding differences to be shown that arise in the tax calculation? (Goal: PDV and XML as an identical multi-part)

Should gross price invoices in the standard context (and thus also in the context of ZUGFeRD 2.x (COMFORT)) be completely dispensed with?

Approaches

ZUGFeRD 1.0 will no longer be maintained. Gross price invoices can be mapped in the ZUGFeRD Extended profile. Consideration of the results of the work of CEN working group 1 --> Transfer of the results to CEN working group 3 (mapping) --> Implementation at national level

Further Procedure

Mr Michalewicz provides the statement of the BMF. (Ms Behre forwarded the BMF's information to this working group by e-mail on 18 November 2020, 4.27 p.m.)

is currently being discussed in CEN

Update: Implementation in Extension as soon as technical solution available. TC434 WG3 is currently working on a proposal to be awaited.

[edmundgray]

Item Gross Price (BT-148) is optional in the Core. A CIUS should be used if it is required.

[phax]

@edmundgray This is about all prices being gross instead of net I assume. It's not just about BT-148.

[edmundgray]

@phax we are discussing these issues tomorrow morning at 10 in WG5. It would be good if you could join us

[phax]

It's too short notice unfortunately - I am holding a Webinar. Trying to get the meetings back in my calendar

[edmundgray]

@phax In the meantime we appreciate any comments made

[svanteschubert]

This issue is (likely) already being solved as there is a new data field BT-181 in the upcoming EN16931 core amendment

[phax]

Oh, that will create rounding issues and non-matching sums 😆

[svanteschubert]

There will be a ground truth for rounding in the amendments:

1. Arithmetic on decimals should be as accurate as if using the decimal-based floating-point standard defined in IEEE/ISO/IEC 60559-2020
2. Rounding should be performed "round-to-the-nearest" half-up away from zero (1,005 is rounded to 1,01 and -1,005 is rounded to -1,01)
3. There should be no calculation of intermediate values if avoidable (e.g. do not add line-level gross values, if net values could be added)

[phax]

The rules are especially important for the Tax Totals and the monetary total. Maybe some calculation rules can be provided as "Best practise" so that they are not binding but solid recommendations

[edmundgray]

I think before we decide we should go through a process like this?

• Are we sure that the requirement here is for a Price inclusive of VAT - or would BT-148 be OK (i.e. before discount is applied but also exclusive of VAT). Nowhere in the text above does it mention VAT. If the requirement requires a VAT inclusive price;
• What is the Use Case? - B2G, B2B, or B2C.
• If it is for B2C, this is handled by eReceipt, so should suffice? Otherwise;
• If not B2C, is this commonly required on an invoice. (I think not)
• If not commonly used, then it must be handled by an Extension.
• If it is required by law in a country, it is a National Extension.

We need to then discuss should it be part of the calculations, if so, this will complicate the requirements, and as Philip states we need to provide examples and best practice to avoid the confusion.

[svanteschubert]

On today's CEN TC 434 WG 1 call this issue was decided to be moved from core amendment to extension as many countries (their national standardisation body members) had voted down this proposal earlier.