A specification based on Universal Business Language (UBL) that enables the exchange of compliant business documents worldwide via our e-business platform Pagero Online.
1. Introduction
Pagero Universal Format, hereafter referred to as "PUF", is a collection of business document specifications developed and maintained by Pagero Group.
All response message types within the PUF suite implement the UBL 2.3 XML structure.
The PUF landing page lists all document types supported in the suite and in which directions these are available.
To align with new regulation and business needs throughout the world, the core idea of PUF is to enable its users to send/receive the data required to meet requirements in these markets and jurisdictions.
Based on extensive analysis, PUF has been designed to meet various country-, industry-, format- and/or system-specific requirements.
Another core idea of PUF is to create flexible, extendable business document specifications which can be updated quickly to meet the requirements of the fast-changing global electronic document landscape.
PUF will to a large extent try to follow and align with the work done in OpenPeppol and other UBL based specifications.
1.1. Version and changelog
Version |
Date |
Description |
1.0 |
2023-01-27 |
First version published. |
1.2. Response messages in general
| This specification concerns the Invoice Response message type. |
When issuing an electronic document (e.g. electronic invoice or other document type) there might be a need to inform about the process status of that document during its lifecycle.
This can include information about the transport of a message, status regarding clearance/reporting of a message or status of a message concerning the recipients approval or rejection etc.
Depending on which legal domain the document issuer operates in, the need for various response messages might differ.
The response message types available in the PUF suite for use in Pagero Online are:
Example: A possible orchestation of messages supporting a market where invoices are required to be reported to a clearance authority and where a buyer has the possibility to send an invoice response.
1.2.1. Technical acknowledgement
This type of response message is mainly used to inform a sender about the transport of a document from
point A to B.
In addition, in Pagero Online the use of technical acknowledgements is used for informing the sender about technical validation results such as XML schema validations, schematron errors etc.
1.2.2. Clearance notification
The use of the Clearance Notification message type is applicable in clearance and CTC markets where documents needs to be cleared or reported to the government or another assigned authority.
It will inform the issuer of an document of the clearance/reporting status (i.e. rejected or accepted) but can also contain clearance artefacts such as QR codes or a signed cleared document.
1.2.3. Invoice response
This is often referred to as business level response.
It is a document issued by the recipient/buyer to inform the issuer of an invoice about business decisions.
The delivered invoice may be technically correct and delivered to the recipient/buyer but there might be the need for a buyer to inform the issuer if the invoice is accepted or if there is a reason for a rejection.
2. Guidelines
PUF Invoice Response is a document type that is applicable to be exchanged between buyer/receiver and supplier/issuer to inform the issuer of an invoice about business decisions.
This is often referred to as business level response.
PUF Invoice Response is developed to be compliant to the UBL 2.3 schema.
In areas where support for certain information is available in the existing UBL 2.3 schema, PUF implements these elements.
In other areas where there are no suitable elements in the existing UBL 2.3 schema, PUF implements ext:UBLExtensions.
2.1. How to get started
In the following chapters you can see which elements and what type of information that PUF Invoice Response supports.
In some cases we provide longer snippets of code and implementation guidelines describing how to properly interpret the data.
There is also a section with Examples that can be useful when building support for PUF Invoice Response in various markets.
If your ERP system already can receive/issue documents in UBL 2.3 or if your ERP system can interpret/create another UBL 2.3 based format you can easily use this as stepping stone when moving towards PUF.
2.2. Namespaces
Target root name space - ApplicationResponse:
-
urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2
Example:
ApplicationResponse example for target namespace
<ApplicationResponse xmlns="urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2">
<!-- Code omitted for clarity -->
</ApplicationResponse>2.3. Customization and Profile ID
To indicate the correct PUF specification identifer and the profile identifier, the values in below table must be sent in cbc:CustomizationID and cbc:ProfileID.
The two types (Invoice Response and Document Status) represent two different underlying business processes and are selected based on the role the sending party has in that process:
-
Invoice Response is used when the buyer provides a business status update for a referenced document.
-
Document Status is used when the seller provides a business status update for a referenced document.
The supported statuses and content is the same in both types; only the sender’s role (buyer or seller) differs.
| Type | Element cbc:CustomizationID |
Element cbc:ProfileID |
Process/Business roles |
|---|---|---|---|
Invoice Response |
urn:pagero.com:puf:invoice_response:1.0 |
urn:pagero.com:puf:invoice_response:1.0 |
Buyer to Seller |
Document Status |
urn:pagero.com:puf:document_status:1.0 |
urn:pagero.com:puf:document_status:1.0 |
Seller to Buyer |
Example
<ApplicationResponse>
<!-- Code omitted for clarity -->
<cbc:CustomizationID>urn:pagero.com:puf:invoice_response:1.0</cbc:CustomizationID>
<cbc:ProfileID>urn:pagero.com:puf:invoice_response:1.0</cbc:ProfileID>
<!-- Code omitted for clarity -->
</ApplicationResponse>2.4. Working with extensions
This chapter provides an overview the use of extensions.
In order to facilitate the use of PUF specific extensions, an additional XML schema is provided.
The PUF-ExtensionComponent.xsd can be found together with the other schemas in chapter XML schemas.
To be able to use the PUF-ExtensionComponent, its namespace must be included in the document file.
Example
Example from ApplicationResponse
<ApplicationResponse ... xmlns:puf="urn:pagero:ExtensionComponent:1.0">
<!-- Code omitted for clarity -->
</ApplicationResponse>Depending on in which context the UBLExtensions are used, there are different options for what types of values that can be provided.
To identify which context the UBLExtensions is in, the element ExtensionURI is used.
When using these Pagero extensions, the URI always has the same base:
-
urn:pagero:ExtensionComponent:1.0:PageroExtension
After this URI, the specific resource name is added.
Example
UBLExtension used in the cac:Response structure.
<ApplicationResponse>
<!-- Code omitted for clarity -->
<cac:Response>
<ext:UBLExtensions>
<ext:UBLExtension>
<ext:ExtensionURI>urn:pagero:ExtensionComponent:1.0:PageroExtension:ResponseExtension</ext:ExtensionURI>
<!-- Code omitted for clarity -->
</cac:Response>
<!-- Code omitted for clarity -->
</ApplicationResponse>For detailed examples and how to use possible values in each extension please see the chapters where PUF-specific elements are described.
2.5. Document reference matching
An Invoice Response always corresponds to an Invoice document. When transmitting the PUF Invoice Response, there are several methods by which Pagero Online establishes a connection between the Invoice Response and its corresponding Invoice (assuming the Invoice is present within Pagero Online).
Pagero Online will attempt to match the response based on specific values. The xpaths for these are prioritized and used in the sequence listed below:
-
cac:DocumentResponse/cac:Response/ext:UBLExtensions/ext:UBLExtension[ext:ExtensionURI = 'urn:pagero:ExtensionComponent:1.0:PageroExtension:ResponseExtension']/ext:ExtensionContent/puf:PageroExtension/puf:ResponseExtension/puf:DocumentMatchingID/cbc:ID -
cac:DocumentResponse/cac:Response/ext:UBLExtensions/ext:UBLExtension[ext:ExtensionURI = 'urn:pagero:ExtensionComponent:1.0:PageroExtension:ResponseExtension']/ext:ExtensionContent/puf:PageroExtension/puf:ResponseExtension/puf:DocumentMatchingID/cbc:UUID -
Combined segment information:
-
cac:DocumentResponse/cac:Response/cac:DocumentReference/cbc:ID -
cac:DocumentResponse/cac:Response/cac:DocumentReference/cbc:IssueDate -
cac:SenderParty/cac:PartyIdentification/cbc:ID -
cac:ReceiverParty/cac:PartyIdentification/cbc:ID
-
For this last option, the identifiers (cac:PartyIdentification/cbc:ID) from both the sender and receiver parties must correspond to those present in the Invoice document within Pagero Online. Additionally, the invoice number and date should also align.
You can read more about DocumentMatchingID in puf:ResponseExtension
If Pagero Online is unable to match the referenced document, the identifiers provided in cac:ReceiverParty will be used for routing the response to the recipient.
|
2.6. Release management
PUF will be continuously updated to meet new market demands.
2.6.1. Minor release
A minor release will always be backward compatible and will take place without prior notice and will be implemented whenever needed.
Minor releases may include bugfixes, new elements, schematron updates and other features.
To be automatically notified of all releases, please "Watch" the project repository on GitHub.
2.6.2. Major release
A major release may include changes that are not backward compatible.
Such a release will be notified at least three months prior to date of implementation, to users who registered an account on Pagero validex or on GitHub.
To register for PUF major release notification you can create a free account on Pagero Validex.
But we strongly urge all interested parties to "Watch" the project repository on GitHub where all releases will trigger automatic notifications.
3. Syntax
The chapter describes the ApplicationResponse syntax binding and all available document content.
ApplicationResponse
| This is the root element in the UBL XML schema. |
cbc:CustomizationID
| Path | Description |
|---|---|
|
Document specification identifier |
Example
cbc:CustomizationID populated with correct value
<ApplicationResponse>
<!-- Code omitted for clarity -->
<cbc:CustomizationID>urn:pagero.com:puf:invoice_response:1.0</cbc:CustomizationID>
<!-- Code omitted for clarity -->
</ApplicationResponse>cbc:ProfileID
| Path | Description |
|---|---|
|
Business process type |
Example
cbc:ProfileID populated with correct value
<ApplicationResponse>
<!-- Code omitted for clarity -->
<cbc:ProfileID>urn:pagero.com:puf:invoice_response:1.0</cbc:ProfileID>
<!-- Code omitted for clarity -->
</ApplicationResponse>cbc:ID
| Path | Description |
|---|---|
|
Invoice reponse identifer |
Example
cbc:ID with example value
<ApplicationResponse>
<!-- Code omitted for clarity -->
<cbc:ID>51234882</cbc:ID>
<!-- Code omitted for clarity -->
</ApplicationResponse>cbc:IssueDate
| Path | Description |
|---|---|
|
Issue date of the invoice reponse |
Example
cbc:IssueDate with example value
<ApplicationResponse>
<!-- Code omitted for clarity -->
<cbc:IssueDate>2021-01-30</cbc:IssueDate>
<!-- Code omitted for clarity -->
</ApplicationResponse>cbc:IssueTime
| Path | Description |
|---|---|
|
The time at which the transaction instance was issued. |
Example
cbc:IssueTime with example value
<ApplicationResponse>
<!-- Code omitted for clarity -->
<cbc:IssueTime>21:32:52</cbc:IssueTime>
<!-- Code omitted for clarity -->
</ApplicationResponse>cbc:Note
| Path | Description |
|---|---|
|
Note |
Example
cbc:Note example
<ApplicationResponse>
<!-- Code omitted for clarity -->
<cbc:Note>This</cbc:Note>
<cbc:Note>is a</cbc:Note>
<cbc:Note>free text example</cbc:Note>
<!-- Code omitted for clarity -->
</ApplicationResponse>cac:SenderParty
| Path | Description |
|---|---|
|
Electronic Identifier |
|
Electronic Identifier scheme ID |
|
Sender party identifier |
|
Sender party identifier scheme id |
|
Sender party name |
|
Sender party contact point name |
|
Sender party contact point telephone |
|
Sender party contact point email |
Example
cac:SenderParty with example values
<ApplicationResponse>
<!-- Code omitted for clarity -->
<cac:SenderParty>
<cbc:EndpointID schemeID="0088">7310000000000</EndpointID>
<cac:PartyLegalEntity>
<cbc:RegistrationName>Sender party name</cbc:Name>
</cac:PartyLegalEntity>
</cac:SenderParty>
<!-- Code omitted for clarity -->
</ApplicationResponse>cac:ReceiverParty
| Path | Description |
|---|---|
|
Electronic Identifier |
|
Electronic Identifier scheme ID |
|
Receiver party identifier |
|
Receiver party identifier scheme id |
|
Receiver’s party name |
Example
cac:ReceiverParty with example values
<ApplicationResponse>
<!-- Code omitted for clarity -->
<cac:ReceiverParty>
<cbc:EndpointID schemeID="0088">7310000000000</EndpointID>
<cac:PartyLegalEntity>
<cbc:RegistrationName>Receiver party name</cbc:Name>
</cac:PartyLegalEntity>
</cac:ReceiverParty>
<!-- Code omitted for clarity -->
</ApplicationResponse>cac:DocumentResponse
cac:Response
| Path | Description |
|---|---|
|
Extension Content |
|
Invoice status |
|
Extension Content |
|
Status reason code The primary purpose of the |
|
Status reason code list identifier For status clarification reasons (i.e. why the status is given), set For requested actions (i.e. what the recipient is asked to do), set |
|
Status reason text |
Example
cac:Response with example values
<ApplicationResponse>
<!-- Code omitted for clarity -->
<cac:DocumentResponse>
<cac:Response>
<ext:UBLExtensions>
<ext:UBLExtension>
<ext:ExtensionURI>urn:pagero:ExtensionComponent:1.0:PageroExtension:ResponseExtension</ext:ExtensionURI>
<ext:ExtensionContent>
<puf:PageroExtension>
<puf:ResponseExtension>
<puf:ReferencedDocumentInterchangeID>
<cbc:ID>123456789</cbc:ID>
</puf:ReferencedDocumentInterchangeID>
<puf:DocumentMatchingID>
<!-- Either cbc:ID or cbc:UUID can be used, see Extensions documentation -->
<cbc:ID>123456789</cbc:ID>
<cbc:UUID>4408ca72-f3c0-11ed-a05b-0242ac120003</cbc:UUID>
</puf:DocumentMatchingID>
<puf:AdditionalDocumentReference>
<cbc:ID>1456123</cbc:ID>
<cbc:DocumentTypeCode>M</cbc:DocumentTypeCode>
<cbc:DocumentDescription>LCD</cbc:DocumentDescription>
<cac:Attachment>
<cbc:EmbeddedDocumentBinaryObject filename="123456789_12345.xml" mimeCode="application/xml">U29tZSBkb2N1bWVudA==</cbc:EmbeddedDocumentBinaryObject>
</cac:Attachment>
</puf:AdditionalDocumentReference>
</puf:ResponseExtension>
</puf:PageroExtension>
</ext:ExtensionContent>
</ext:UBLExtension>
</ext:UBLExtensions>
<cbc:ResponseCode>APPROVED</cbc:ResponseCode>
<cac:Status>
<cbc:StatusReasonCode>XSD_ZATCA_VALID</cbc:StatusReasonCode>
<cbc:StatusReason>Complied with UBL 2.1 standards in line with ZATCA specifications</cbc:StatusReason>
</cac:Status>
</cac:Response>
<!-- Code omitted for clarity -->
</ApplicationResponse>cac:DocumentReference
| Path | Description |
|---|---|
|
Invoice identifier |
|
Invoice issue date |
|
Document type code |
Example
cac:DocumentReference with example values
<ApplicationResponse>
<!-- Code omitted for clarity -->
<cac:DocumentResponse>
<cac:Response>
<!-- Code omitted for clarity -->
<cac:DocumentReference>
<cbc:ID>INV002</cbc:ID>
<cbc:IssueDate>2022-09-07</cbc:IssueDate>
<cbc:DocumentTypeCode>380</cbc:DocumentTypeCode>
</cac:DocumentReference>
<!-- Code omitted for clarity -->
</cac:Response>
<!-- Code omitted for clarity -->
</ApplicationResponse>4. Extensions
4.1. Response extension
Below chapter describes the elements added in cac:DocumentResponse/cac:Response/ext:UBLExtensions.
4.1.1. puf:ResponseExtension
Below tables shows the definition of elements added to the extension puf:PageroExtension/puf:ResponseExtension.
| Element | Description |
|---|---|
|
Returnable restricted information |
| Element | Description |
|---|---|
|
Referenced document interchange identifier |
|
Referenced document matching identifier |
|
Referenced API document matching identifier |
| Element | Description |
|---|---|
|
Additional document reference identifier |
|
Additional document reference type code |
|
Additional document reference description |
|
Additional document reference filename |
|
Additional document reference MIME code |
|
Additional document reference binary object |
See example below as well as the URI to be used for this extension.
Example
puf:ResponseExtension with sample values.
<ApplicationResponse>
<!-- Code omitted for clarity -->
<cac:DocumentResponse>
<cac:Response>
<ext:UBLExtensions>
<ext:UBLExtension>
<ext:ExtensionURI>urn:pagero:ExtensionComponent:1.0:PageroExtension:ResponseExtension</ext:ExtensionURI>
<ext:ExtensionContent>
<puf:PageroExtension>
<puf:ResponseExtension>
<puf:ReferencedDocumentInterchangeID>
<cbc:ID>123456789</cbc:ID>
</puf:ReferencedDocumentInterchangeID>
<puf:DocumentMatchingID>
<!-- Either cbc:ID or cbc:UUID can be used, see Extensions documentation -->
<cbc:ID>123456789</cbc:ID>
<cbc:UUID>4408ca72-f3c0-11ed-a05b-0242ac120003</cbc:UUID>
</puf:DocumentMatchingID>
<puf:AdditionalDocumentReference>
<cbc:ID>1456123</cbc:ID>
<cbc:DocumentTypeCode>M</cbc:DocumentTypeCode>
<cbc:DocumentDescription>LCD</cbc:DocumentDescription>
<cac:Attachment>
<cbc:EmbeddedDocumentBinaryObject filename="123456789_12345.xml" mimeCode="application/xml">U29tZSBkb2N1bWVudA==</cbc:EmbeddedDocumentBinaryObject>
</cac:Attachment>
</puf:AdditionalDocumentReference>
</puf:ResponseExtension>
</puf:PageroExtension>
</ext:ExtensionContent>
</ext:UBLExtension>
</ext:UBLExtensions>
</cac:Response>
<!-- Code omitted for clarity -->
</ApplicationResponse>5. Country specifics
This section will provide information on how common country specific data in PUF Invoice Response is implemented.
5.1. France
This section contains requirements and other information concerning the use of PUF Invoice Response in France.
5.1.1. Payment reporting
In France it is a requirement to report received payments for certain transactions to the Tax Authority. The PUF Invoice Response format has been extended with additional elements relating to payment amounts to facilitate this. The full list of elements is available in puf:ResponseExtension.
Amount Type
The <puf:AmountType> element is used to indicate what the specified amounts mean. In France, the following list is applicable:
| Code | Definition |
|---|---|
|
Amount collected (incl. tax) |
|
Amount paid |
|
Remaining to pay (in case of partial payment) |
|
Discount granted |
|
Rebate granted |
|
Reduction granted |
|
Net Amount Approved |
|
Gross Amount Approved (incl. tax) |
|
Net Amount NOT Approved |
|
Gross Amount NOT Approved (incl. tax) |
MEN (with accompanying cbc:TaxInclusiveAmount and cbc:Percent) is the only type required by the Tax Authority, but the other Amount Types (puf:AmountType) and related data fields (cbc:TaxExclusiveAmount) are useful to convey additional information to the receiving party and can be used in addition to MEN.
|
Generally, only one "amount" per puf:Amount should be sent, i.e. choose to use either cbc:TaxExclusiveAmount or cbc:TaxInclusiveAmount, not both.
|
Example
puf:StatusExtension with sample values. The example scenario illustrated below is an invoice for €1310 (incl. VAT) with two VAT rates (20 % and 10 %). The taxpayer reports that two amounts have been paid: €120 (incl. 20 % VAT) and €11 (incl. 10 % VAT). In addition to this, the taxpayer also informs the recipient that they have €1080 (incl. 20 % VAT) and €99 (incl. 10 % VAT) remaining to be paid (RAP).
<ApplicationResponse>
<!-- Code omitted for clarity -->
<cac:DocumentResponse>
<cac:Response>
<cac:Status>
<ext:UBLExtensions>
<ext:UBLExtension>
<ext:ExtensionURI>urn:pagero:ExtensionComponent:1.0:PageroExtension:StatusExtension</ext:ExtensionURI>
<ext:ExtensionContent>
<puf:PageroExtension>
<puf:StatusExtension>
<!-- Code omitted for clarity -->
<puf:Amounts>
<puf:Amount>
<puf:AmountType>MEN</puf:AmountType>
<cbc:TaxInclusiveAmount currencyID="EUR">120.00</cbc:TaxInclusiveAmount>
<puf:ClassifiedTaxCategory>
<cbc:Percent>20</cbc:Percent>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</puf:ClassifiedTaxCategory>
</puf:Amount>
<puf:Amount>
<puf:AmountType>MEN</puf:AmountType>
<cbc:TaxInclusiveAmount currencyID="EUR">11.00</cbc:TaxInclusiveAmount>
<puf:ClassifiedTaxCategory>
<cbc:Percent>20</cbc:Percent>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</puf:ClassifiedTaxCategory>
</puf:Amount>
<puf:Amount>
<puf:AmountType>RAP</puf:AmountType>
<cbc:TaxInclusiveAmount currencyID="EUR">1080.00</cbc:TaxInclusiveAmount>(1)
<puf:ClassifiedTaxCategory>
<cbc:Percent>20</cbc:Percent>(2)
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</puf:ClassifiedTaxCategory>
</puf:Amount>
<puf:Amount>
<puf:AmountType>RAP</puf:AmountType>
<cbc:TaxInclusiveAmount currencyID="EUR">99.00</cbc:TaxInclusiveAmount>
<puf:ClassifiedTaxCategory>
<cbc:Percent>10</cbc:Percent>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</puf:ClassifiedTaxCategory>
</puf:Amount>
</puf:Amounts>
</puf:StatusExtension>
</puf:PageroExtension>
</ext:ExtensionContent>
</ext:UBLExtension>
</ext:UBLExtensions>
</cac:Status>
</cac:Response>
<!-- Code omitted for clarity -->
</ApplicationResponse>| 1 | Either of cbc:TaxExclusiveAmount and cbc:TaxInclusiveAmount may be relevant for some Amount Types. Here cbc:TaxInclusiveAmount is used to show total (incl. VAT) amount remaining to be paid. |
| 2 | cbc:Percent may also be relevant for some Amount Types. In this example the "amount remaining to be paid" (RAP) has been split per VAT rate. |
5.1.2. Status Reason
It is possible to provide a reason as to why a certain response (e.g. Refused) is being sent.
See the section cac:Response for additional details.
In France, the reason codes are unique and defined in the table below. The table also indicates for which response codes (cbc:ResponseCode) each reason code is applicable.
| French code | Label | Description | PARTIALLY_ACCEPTED (206) | UNDER_QUERY (207) | ON_HOLD (208) | REJECTED (210) |
|---|---|---|---|---|---|---|
|
Incorrect Total Amount |
One of the invoice total amounts is incorrect, for example Net payable |
❌ |
✅ |
❌ |
✅ |
|
Invoice calculation error |
Either detected at schematron, or afterwards (for lines, or rounding not accepted) |
❌ |
✅ |
❌ |
✅ |
|
Missing legal information |
Any missing legal information that hasn’t been checked by systematic validations. |
❌ |
✅ |
❌ |
✅ |
|
Duplicate invoice (already issued / received) |
Duplicate invoice (same number, same supplier and same year of invoice date) |
❌ |
✅ |
❌ |
✅ |
|
Recipient error |
The legal entity recipient of the invoice is not the correct one (recipient’s SIREN number). For example in case of multi-company within a group, and the billed company is not the one that should have been. |
❌ |
✅ |
❌ |
✅ |
|
Unknown transaction |
The invoice does not correspond to a delivery made or a service rendered. |
❌ |
✅ |
❌ |
✅ |
|
Unknown issuer |
The invoice issuer is unknown to the Recipient (anti-spam) |
❌ |
✅ |
❌ |
✅ |
|
Contract terminated |
Contract terminated, no more invoicing possible |
❌ |
✅ |
❌ |
✅ |
|
Double invoice |
Service or delivery already invoiced on another invoice |
❌ |
✅ |
❌ |
✅ |
|
Incorrect or missing order number |
Order number incorrect, non-existent or already invoiced. Can only be used together with rejected (210) status if the order number was provided by the buyer before invoicing. |
✅ |
✅ |
✅ |
✅ |
|
Incorrect electronic billing address |
The recipient’s electronic billing address (BT-49 or BT-34) is absent or incorrect |
❌ |
✅ |
❌ |
❌ |
|
Incorrect or missing SIRET |
The recipient’s SIRET is incorrect or missing when required |
✅ |
✅ |
✅ |
❌ |
|
Incorrect or missing ROUTING_CODE |
The recipient’s ROUTING_CODE is incorrect or missing when required |
✅ |
✅ |
✅ |
❌ |
|
Contractual reference required for invoice processing is missing |
Contractually required reference is absent (list to be defined) and to be identified in the lifecycle: BT-12 (Contract number), Delivery note number (BT-16), Buyer reference (BT-10), Invoiced object (BT-18), Project reference (BT-11), Previous invoice (BG-3) etc. |
✅ |
✅ |
✅ |
✅ |
|
Incorrect reference |
The specific incorrect reference is identified in the other data fields |
✅ |
✅ |
✅ |
❌ |
|
Incorrect unit prices |
A unit price is not as expected |
✅ |
✅ |
❌ |
❌ |
|
Incorrect discount |
A discount is missing or is not as expected |
✅ |
✅ |
❌ |
❌ |
|
Incorrect invoiced quantity |
An invoiced quantity is not as expected |
✅ |
✅ |
❌ |
❌ |
|
Incorrect invoiced item |
An invoiced item is incorrect |
✅ |
✅ |
❌ |
❌ |
|
Incorrect payment terms |
The payment terms (e.g., due date) are not as expected |
✅ |
✅ |
❌ |
❌ |
|
Incorrect quality of delivered item |
One (or more) of the delivered items is defective |
✅ |
✅ |
❌ |
❌ |
|
Delivery problem |
Incomplete or non-compliant delivery |
✅ |
✅ |
❌ |
❌ |
Example
cac:Response with response code RE (EN: Rejected/Refused, FR: 210) and reason code MONTANTTOTAL_ERR (Incorrect Total Amount).
<ApplicationResponse>
<!-- Code omitted for clarity -->
<cac:DocumentResponse>
<cac:Response>
<cbc:ResponseCode>RE</cbc:ResponseCode>
<cac:Status>
<cbc:StatusReasonCode listID="OPStatusReason">MONTANTTOTAL_ERR</cbc:StatusReasonCode>
<cbc:StatusReason>One of the invoice total amounts is incorrect</cbc:StatusReason>
</cac:Status>
</cac:Response>
<!-- Code omitted for clarity -->
</cac:DocumentResponse>
</ApplicationResponse>5.1.3. Requested Action
It is possible to request the recipient of the PUF Invoice Response to perform a certain action (generally to resolve a dispute). A common example scenario could be one where the Buyer requests that the Seller issues a new invoice, as the current one has incorrect data.
See the section cac:Response for additional details.
In France, the action codes will follow the Peppol list OPStatusAction.
| Only the Action Code list follows Peppol. The Reason code list is unique to France and can be found in the Status Reason section above. |
6. Code lists
Certain elements require the use of PUF specific code lists. Below you will find the lists and where the lists are applicable.
In some of these code lists PUF only points towards an external code list to be used.
Other times the code list to be used is a mix between values defined specifically for PUF and other external list(s).
Lastly, in some cases, all the values are defined solely for PUF.
6.1. Code lists for coded elements
| Business Term | Path | listID |
|---|---|---|
Mime code |
|
|
Electronic address scheme |
|
|
Identification scheme |
|
|
Invoice status codes |
|
7. XML schemas
The PUF Invoice Response XML schemas including Pagero/PUF Extension can be downloaded here:
8. Excel specification
This document refers to an Excel file that serves as an additional mapping guide for the Pagero Universal Format (PUF) in complement to the online documentation. It’s designed to provide an essential understanding of the structure and core components of the PUF.
Please note that the guide is intended to be used only when sending PUF Invoice Response.
The Excel file can be accessed through the following link:
9. Validation
To validate PUF documents please create a free account on Pagero Validex.
The validations available on Validex are:
-
XML well-formedness
-
XSD schema
-
PUF business (schematron) rules (if applicable)
The validation artefacts are also available on GitHub.
10. Examples
Example files can be downloaded here:
11. Support
If you have any questions related to PUF, please create a support ticket via Pagero Support.