Special rules for the currency HUF

[phax]

Question from Germany:

• In Hungary, it is customary that amounts are not issued here with two decimal places, but are always rounded to full HUF. So the indication of the fillers is omitted.
• If we now transfer these amounts (rounded to full HUF) to the xInvoice, then the xInvoices will run into errors in the KoSIT Validator and will be rejected, because this validator also performs the validation between VAT rate, net, VAT amount and gross with two decimal places for HUF.
• However, in the standard SAP system, HUF amounts are always rounded to full HUF, i.e. without decimal places.
• So how do we handle the HUF amounts in the EN invoices without them being rejected by the current Schematron validations.
• Even in international payments there are only the full HUF without filler.

The proposal would be to add a final rounding at the end, in case the document currency is HUF

[oriol]

Could you please provide some example files?

[phax]

Here you go: huf_example_cii.xml.txt

[oriol]

The sample file does not fire any rule. Can you please send an invoice with this problem @phax ? What are the affected rules?

[AndreasPvd]

Why isn't BT-114 (rounding amount) used to solve this? It is the intended field to correct this kind of currency-dependent rounding issues…

[phax]

Well, in my understanding the reason of the "Slack" was to handle different calculation and rounding models. If the currency clearly states "you have to round for the total amount", it is a different semantic. The same logic needs to be applied to prepaid amounts and all other external amounts that are inside an invoice, so I am convincedm that slack is not the way to go here.

[AndreasPvd]

I see your point regarding external amounts. But the original requirements for the corresponding field in the CEFACT data models linked to the respective field in the CII and for UBL as well (talking about pre 2010) is exactly currency rounding of total amounts. This is the intended semantic definition of this field in EN16931. The other cases to use it as a slack for different calculations was added later during the implementation phase. This is not the original semantic meaning and was chosen as there is currently no other solution available. You can find the definition for instance in the original CEN Workshop agreements, that were used as a basis for EN16931.

[VWeber1965]

Hello everyone,

I'm the one who placed the topic.

BT-114 (rounding amount) is only used here:

• [BR-CO-16] - The content of the element "Amount due for payment" (BT-115) must match the content of the element "Invoice total amount with VAT" (BT-112) minus the content of the element "Paid amount" ( BT-113) plus the content of the item "Rounding amount" (BT-114).

However, our accounting is based on this:

• [BR-CO-17] - The content of the element "VAT category tax amount" (BT-117) must match the content of the element "VAT category taxable amount" (BT-116) multiplied by the content of the element "VAT category rate ' (BT-119) divided by 100, rounded to two decimal places

• But there is no corresponding field "Rounding amount"

[oriol]

Hi @VWeber1965, I think that we need some examples and maybe a discussion in the TC434 as this can be a major change on a business rule.

Could you please send us some sample invoices?

Thanks a lot

[midran]

Hi @AndreasPvd is correct that the purpose of BT-114 is to support rounding of the invoice totals. The slack was not intended to replace this business term but only to prevente unitentional error from VAT validation within the invoice, specially when VAT inclusive priced items need to be entered as VAT exclusive priced.

@phax the title of this ticket is misleading. This is not an issue specific to HUF but any currency where totals are commonly rounded off.

[VWeber1965]

p_21620198615006.xml.txt P_21620198615006-report.html.txt Hi,

we do not have cross-border payment transactions, but what is known as multinational accounting.

It's true that it's not just a HUF problem. However, we only noticed it with the HUF invoices, because in Hungary they calculate with full amounts without decimal places. [BR-CO-17] - VAT category tax amount (BT-117) = VAT category taxable amount (BT-116) x (VAT category rate (BT-119) / 100), rounded to two decimals. 18679 = 69180 x (27.00 / 100) - But the validator calculates 18678.60 and says our calculations are wrong.

Attached is the xInvoice with the error report

[lkumai]

@VWeber1965 I tested your provided test files with the current version and the invoice passed without any error, thus I think the problem is solved now.

[VWeber1965]

That means there is now a new version of the KoSIT validator that can deal with the fact that in Hungary there are only full HUF without decimal places? What's the new version? Has the new version already been stored on ZRE and OZGRE during the initial check?

[phax]

The error for the "slack" in CII was fixed in the CEN rules v1.3.5 (see https://github.com/ConnectingEurope/eInvoicing-EN16931/issues/303#issuecomment-1092573162) - this means, that (to my understanding) starting from rule release 1.6.0 for XRechnung 2.1.1 the problem should have been resolved

[oriol]

I close the issue as it seems to be solved.