-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Major
-
Component/s: None
In the upcoming revision of the core of the European e-Invoice norm, EN16931, the following two semantics have been added for a 3rd party payment/charge:
Previously named business terms (BTs):
1. *Charge amount collected on behalf of a third party*
Charge amount, not part of the invoice, that should be paid as well.
2. *Charges specification*
Specification of the charge amount.
Suggested new named business terms (BTs):
1. Payment amount collected on behalf of a third party
Payment amount, which has its distinct invoice, but is listed and should be paid as well.
2. *Payment specification*
Specification of the payment amount.
A common example would be that the mobile provider of your company phone provides the monthly invoice, including requests to third-party providers, like costs for parking the business car.
The money was paid together with the monthly mobile bill. The mobile provider is similar to a credit card company, just the payer. The invoice is still provided by the 3rd party, but could and should be referenced from this invoice.
The payment is declared very similar to the listing of payments of a credit card in a bank account.
A distinct invoice does exist, issued by the 3rd party.
In the following example, a mobile provider includes the payment for the purchase of a parking ticket:
Example in German:
Example in English (picture translated by ChatGPT):
It would be helpful to provide UBL XML for the 2 required semantics of the core invoice.
In addition, it would be helpful to gather requirements to provide a full-featured structured data set for the feature of 3rd Party Payment.
For instance, the document reference / URL to the 3rd party invoice could be very desirable.
Other examples would be helpful to assist in the design of the structure.
For instance, there can be multiple purchases and multiple 3rd party vendors (within a month) in an invoice.
The unstructured provision of various data sets in a single text field seems suboptimal as well. From the above example alone, the following data was identified:
1. Title/Header:
PayByPhone Parkticket Einzelkauf
2. Provideraddress:
Anbieter: PayByPhone Deutschland GmbH, Allee am Röthelheimpark 15, 91052 Erlangen
3. Telefon contact
Tel. 01234567.
4. URLs for help and further information
_https://payments.vodafone.com_ e.g.
_https://payments.vodafone.com/de_
_https://zeph.info/vodafone_
The third URL provides a table in PDF, which contains all contact addresses of Third-Party Providers for Mobile Phone Bill Payment!
You may find the following columns/semantics in the PDF table of https://zeph.info/vodafone
- Third-Party Provider
- Status
- Street
- House No.
- Postal Code
- City
- Country
- Phone
- Email Address (Support)
- Authorised Recipient in the customer's country (here Germany)
- Authorised Recipient Street
- Authorised Recipient House No.
- Authorised Recipient Postal Code
- Authorised Recipient City
- Deactivation Date
Although the example provided a 0% VAT, this could be stated implicitly, as the VAT would always be stated in the invoice of the 3rd party.