This guide delineates the application of the UBL 2.4 Application Response schema, conforming to UBL 2.4 standards. Its primary function is to relay the status of billing document submissions to tax authorities. Dispatched from the tax authority through vendors to Google, the document crucially informs on the submission status and may include links to any generated invoice binary files by the tax administration.
The schema facilitates vendors in reporting outcomes of document submissions to Google, covering:
- Acceptance status of documents.
- Issues or errors identified by the tax authority.
- Links to related binary files for invoices or credit notes.
This structured communication protocol ensures seamless interaction between Google, vendors, and tax authorities, enhancing the efficiency of invoice processing and compliance adherence.
Similar to the batching mechanism used for requests, the response batching approach consolidates multiple documents in a single submission for more effective management. Detailed insights on this mechanism can be found in the invoice response batching section.
The schema structure, visualized in the image, illustrates the document's organization and critical components, underscoring the approach to status reporting of invoice submissions:
1.0 Application response header
Details essential metadata such as the Google Vendor Request ID and the date and time when the response was issued in UTC.
Element | Description | Example |
---|---|---|
cbc:UUID |
Google Vendor Request ID provided in the invoice request. | 123e4567-e89b-12d3-a456-426614174000 |
cbc:IssueDate |
Date the response was issued. | 2023-06-02 |
cbc:IssueTime |
Time the response was issued, in UTC. | 08:20:00-08:00 |
Example
<ApplicationResponse>
<cbc:UUID>123e4567-e89b-12d3-a456-426614174000</cbc:UUID>
<cbc:IssueDate>2023-06-02</cbc:IssueDate>
<cbc:IssueTime>08:20:00-08:00</cbc:IssueTime>
<cac:SenderParty>
<!-- Sender party details -->
</cac:SenderParty>
<cac:ReceiverParty>
<!-- Receiver party details -->
</cac:ReceiverParty>
<cac:DocumentResponse>
<!-- Document Response content -->
</cac:DocumentResponse>
</ApplicationResponse>
2.0 Sender and receiver information
This section provides information about the sender and receiver of the Application Response, a mandatory field as per the UBL standard. In this context, the sender is expected to be the vendor who forwards the response from the government system, and the receiver should be Google.
Element | Description | Example |
---|---|---|
cac:SenderParty/cac:PartyName/cbc:Name |
Name of the vendor forwarding the response from the government system. | Vendor Company |
cac:ReceiverParty/cac:PartyName/cbc:Name |
Name of the entity receiving the response. | Google |
Example
<ApplicationResponse>
...
<cac:SenderParty>
<cac:PartyName>
<cbc:Name>Vendor Company</cbc:Name>
</cac:PartyName>
</cac:SenderParty>
<cac:ReceiverParty>
<cac:PartyName>
<cbc:Name>Google</cbc:Name>
</cac:PartyName>
</cac:ReceiverParty>
...
</ApplicationResponse>
3.0 Document response
This section provides details about the document response, encompassing both the response's status and any associated document references generated as a result of successful document submission to the government.
Element | Description | Example |
---|---|---|
cac:Response |
Mandatory. Contains the response status related to the invoice submission. | Refer to section 3.1 |
cac:DocumentReference |
Optional. Can include zero or many references to documents generated. | Refer to section 3.2 |
Example
<ApplicationResponse>
...
<cac:DocumentResponse>
<cac:Response>
<!-- Response details -->
</cac:Response>
<cac:DocumentReference>
<!-- Document Reference (if applicable) -->
</cac:DocumentReference>
<cac:DocumentReference>
<!-- Document Reference (if applicable) -->
</cac:DocumentReference>
</cac:DocumentResponse>
</ApplicationResponse>
3.1 Response
Each Application Response should contain a single cac:Response
detailing the
current status, uniquely associated with a document submission. This ensures
that each document processing result is clearly communicated.
Element | Description | Example |
---|---|---|
cbc:ReferenceID |
Unique identifier returned by the tax system for the referenced invoice. | BIL-123456 |
cbc:ReferenceID/@schemeID |
System or standard that provides the identifier, clarifying its source. | KSEF |
cac:Status/cbc:StatusReasonCode |
Code that defines the response or status reason, based on predefined value: list. | NON |
cac:Status/cbc:StatusReason |
Descriptive text providing more details about the status code. | No Issue |
Example
<ApplicationResponse>
...
<cac:DocumentResponse>
<cac:Response>
<cbc:ReferenceID schemeID="Vendor Company">BIL-123456</cbc:ReferenceID>
<cac:Status>
<cbc:StatusReasonCode>NON</cbc:StatusReasonCode>
<cbc:StatusReason>No Issue</cbc:StatusReason>
</cac:Status>
</cac:Response>
<cac:DocumentReference>
<!-- Document Reference (if applicable) -->
</cac:DocumentReference>
<cac:DocumentReference>
<!-- Document Reference (if applicable) -->
</cac:DocumentReference>
</cac:DocumentResponse>
</ApplicationResponse>
3.2 Document reference
This section is used to attach references to documents generated as a result of the invoice submission process. It is optional and can contain multiple references depending on the number of documents generated by the tax authority.
Element | Description | Example |
---|---|---|
cbc:ID |
Local invoice number | BIL-123456 |
cbc:ID/@schemeID |
Identifier of the invoice reference issuer | Vendor Company |
cbc:IssueDate |
Date when this response was issued by tax authorities | 2023-06-02 |
cbc:DocumentTypeCode |
Type of document being referenced, expressed as code (if invoice is accepted) | 380 |
cbc:DocumentType |
Type of document being referenced, expressed as text | Invoice |
cac:Attachment/cac:ExternalReference/cbc:FormatCode |
Format of the generated invoice (XML, PDF, URL) | XML |
cac:Attachment/cac:ExternalReference/cbc:FileName |
Filename of the generated file on the SFTP server (for XML and PDF format codes) | invoice_GCEMEAD0000000001.pdf |
cac:Attachment/cac:ExternalReference/cbc:URI |
URL to retrieve the generated file (for the URL format code) | https://example.com/invoice/view |
These examples illustrate how documents might be referenced in the Application Response. The first example involves documents transferred using SFTP, shown in PDF and XML formats, and the second example demonstrates a document accessible using URL, which simplifies direct access without the need for file transfer protocols.
Example 1: PDF & XML invoice attachments transferred using SFTP
<ApplicationResponse>
<!-- Sender and Receiver Details -->
<cac:DocumentResponse>
<cac:Response>
<!-- Response Details -->
</cac:Response>
<cac:DocumentReference>
<cbc:ID schemeID="Vendor Company">BIL-123456</cbc:ID>
<cbc:IssueDate>2023-06-02</cbc:IssueDate>
<cbc:DocumentTypeCode>380</cbc:DocumentTypeCode>
<cbc:DocumentType>Invoice</cbc:DocumentType>
<cac:Attachment>
<cac:ExternalReference>
<!-- PDF Document stored on SFTP -->
<cbc:FormatCode>PDF</cbc:FormatCode>
<cbc:FileName>invoice_GCEMEAD0000000001.pdf</cbc:FileName>
</cac:ExternalReference>
</cac:Attachment>
<cac:Attachment>
<cac:ExternalReference>
<!-- XML Document stored on SFTP -->
<cbc:FormatCode>XML</cbc:FormatCode>
<cbc:FileName>invoice_GCEMEAD0000000001.xml</cbc:FileName>
</cac:ExternalReference>
</cac:Attachment>
</cac:DocumentReference>
</cac:DocumentResponse>
</ApplicationResponse>
Example 2: Document accessible using URL
<ApplicationResponse>
<!-- Sender and Receiver Details -->
<cac:DocumentResponse>
<cac:Response>
<!-- Response Details -->
</cac:Response>
<cac:DocumentReference>
<cbc:ID schemeID="Vendor Company">BIL-123456</cbc:ID>
<cbc:IssueDate>2023-06-02</cbc:IssueDate>
<cbc:DocumentTypeCode>380</cbc:DocumentTypeCode>
<cbc:DocumentType>Invoice</cbc:DocumentType>
<cac:Attachment>
<cac:ExternalReference>
<!-- Document accessible using URL -->
<cbc:FormatCode>URL</cbc:FormatCode>
<cbc:URI>https://example.com/invoice/view</cbc:URI>
</cac:ExternalReference>
</cac:Attachment>
</cac:DocumentReference>
</cac:DocumentResponse>
</ApplicationResponse>