Guides
Start typing to search…

Billing response: Use cases

The purpose of sending a billing response is to inform the seller about the progress of the invoice processing in the buyer's system.

A billing response is supposed to be issued within three working days after receiving an invoice. In return, depending on the use case, the seller is supposed to issue a new business document, supply additional information, or take no further action.

How the seller handles the action is out of scope and must be managed externally.

The following section outlines the most common use cases in which a billing response is issued. The examples provided for each use case demonstrate how to specify the necessary information in the JSON metadata when sending a billing response.

Invoice is being processed

The buyer has received the invoice but is unable to provide a definite response before the maximum response time expires.

The maximum response time is three working days following the receipt of the invoice. However, the seller should not contact the buyer until another three working days have passed.

In this case, the buyer issues a billing response with the InProcess status within three days of receiving the invoice. The buyer then needs to issue another billing response when the invoice has finished processing.

This does not cover the billing responses with the Other status.

"status": "InProcess"

Invoice is being processed with additional reference data

The buyer has received the invoice and wants to provide additional information to the seller without prompting any other action from the seller.

For example, this can be the invoice receipt date or the invoice reference in the buyer's system. The billing response status is InProcess.

When providing additional information in the billing response metadata, the date when the invoice was received is specified as effectiveDate.

For information such as the internal invoice reference identifier, use the details element.

In details, the type property stores a description of the information shared while the value property contains the information itself.

The expected course of action on the seller's side is defined in the actions array, where type is the action (NoActionRequired) and description might include additional details about the action.

"issueDate": "2019-11-07",
"status": "InProcess",
"effectiveDate": "2019-11-06",
...
"details": [
  {
    "type": "Buyer process reference",
    "value": "INV-191186"
  }
],
"actions": [
  {
    "type": "NoActionRequired"
  }
]

Invoice is being processed but is put on hold.

The buyer has received the invoice but could not complete the processing because of an issue with the invoice or the business process.

This can occur in cases when the buyer was unable to validate the invoice reference number or when the goods have not yet been delivered.

The buyer then lets the seller know that the processing will be continued after updating the invoice details or after the shipment arrives.

In the billing response metadata, the date when the invoice processing will resume is specified as effectiveDate.

The billing response status is InProcess and the additional information regarding the status is given in reasonDescription.

"issueDate": "2019-11-11",
"status": "InProcess",
"effectiveDate": "2019-11-25",
...
"reasonDescription": "We are awaiting the delivery of the items."

Invoice is accepted

The buyer has accepted the invoice and the seller can expect that the invoice will be paid on time. No additional information needs to be provided and the billing response status is Accepted.

"issueDate": "2019-11-04",
"status": "Accepted"

Invoice is rejected

The buyer has rejected the invoice and provided only a textual description of the issue, for example, PO reference is missing.

This means that the buyer has not requested any action from the seller. In the billing response metadata, a description is specified in the reasonDescription property.

To get any further information or resolve the issue, the seller can communicate with the buyer outside of the application. The billing response has the Rejected status.

"issueDate": "2019-11-07",
"status": "Rejected",
...
"reason": "ReferencesIncorrect",
"reasonDescription": "The purchase order reference is missing."

Invoice is rejected and a reissue is requested

The buyer has rejected the invoice and requires that the matter is resolved by issuing the invoice again after corrections are made.

For example, an invoice can be rejected because it does not state the relevant purchase order.

The buyer might not need a credit note if the incorrect invoice has not been booked. In that case, the buyer indicates that the billing response status is Rejected.

In the billing response metadata, the reason for the status is supplied in the reason property (ReferencesIncorrect).

The required action is specified in the type property in the actions array (IssueNewInvoice).

Optionally, the buyer can describe the problem in more details using the description property in actions.

"issueDate": "2019-11-07",
"status": "Rejected",
...
"reason": "ReferencesIncorrect",
...
"action": [
  {
    "type": "IssueNewInvoice"
  }
]

Invoice is rejected and a replacement is requested

The buyer has rejected the invoice that has already been booked in the buyer's system. The buyer then requests a credit note for the incorrect invoice and a new invoice.

The billing response status is then set to Rejected with the explanation specified in the reason property in the billing response metadata. For example, if the invoice is rejected because a reference to the purchase order is missing, reason has the value of ReferencesIncorrect.

The actions expected from the seller are defined in the actions array.

  • When requesting a credit note, the first type property in actions is assigned the value of CreditFully.
  • The second type property in the array is set to IssueNewInvoice.
  • Any further clarifications (description) are optional.
"issueDate": "2019-11-07",
"status": "Rejected",
...
"reason": "ReferencesIncorrect",
...
"action": [
  {
    "type": "CreditFully"
  },
  {
    "type": "IssueNewInvoice"
  }
]

Invoice is conditionally accepted

The buyer can conditionally accept the invoice while proposing new terms.

For example, this can happen if the invoice due date is different from the one previously negotiated between the buyer and the seller.

In the invoice metadata, the status property needs to be set to ConditionallyAccepted and the reason property to PaymentTermsIncorrect.

The buyer can also add more details in reasonDescription.

The updated payment terms are suggested using the details property.

  • In the array, type refers to the element, for example BT-9 or Invoice due date, while value contains the new value of the element. In the example, value would be set to the new payment date.

In case of disagreement with the new payment terms, the seller needs to reach the buyer outside of the application.

Otherwise, no action is necessary.

"issueDate": "2019-10-29",
"status": "ConditionallyAccepted",
...
"reason": "PaymentTermsIncorrect",
"details": [
  {
    "type": "BT-9 (Due date)",
    "value": "2019-12-13"
  }
]

Invoice is under query due to missing or incorrect information

The buyer requests additional information from the seller to be able to continue processing the invoice. The billing response status is UnderQuery and the buyer provides the date on which the invoice processing was put on hold (effectiveDate in the billing response metadata).

This facilitates handling any delays in payment that might occur due to longer processing.

For example, if the invoice is missing a purchase order reference, the reason property in the metadata needs to be set to ReferencesIncorrect.

The clarification for this is given in the details array.

The buyer indicates the missing element in the type property, for example, BT-13 or Purchase order reference, and suggests the correct value as the value property, for example, PO1911548.

Given that the seller needs to communicate the missing information to the buyer, the type property in the actions array must have the value of ProvideMissingInformation.

The buyer can add any other information in the description property in actions.

"issueDate": "2019-11-24",
"status": "UnderQuery",
"effectiveDate": "2019-11-23",
...
"reason": "ReferencesIncorrect",
"details": [
  {
    "type": "BT-13 (Purchase order reference)",
    "value": "PO1911548"
  }
],
"actions": [
  {
    "type": "ProvideInformation"
  }
]

Invoice is under query due to incorrect details and a partial credit note is requested

The buyer has put the invoice processing on hold until the information in the invoice is corrected and a partial refund is issued.

For example, this can occur if the quantity stated on the invoice and the quantity delivered do not match. The buyer resumes the processing after receiving a partial credit note.

In the billing response metadata, the status property is set to UnderQuery.

The clarification of the status is specified in reason as DeliveryIssues and a more detailed description of the status is given in reasonDescription.

Finally, the buyer defines the action that the seller needs to take in the actions array.

  • Here, the seller is supposed to issue a credit note that covers a part of the total costs.
  • The type property in actions is then set to CreditPartially.

The buyer also has the option of providing more details, such as contact information, in the description property of the same array.

"issueDate": "2019-11-24",
"status": "UnderQuery",
"reason": "DeliveryIssues",
"reasonDescription": "For item with the item number VH5Y11LA7P (line no. 3 in the invoice) the ordered and invoiced quantity was 6 units. We have received only 5 units. Please issue a credit note for the missing item.",
"actions": [
  {
    "type": "CreditPartially"
  }
]

Invoice payment is initiated

The buyer notifies the seller that the invoice has been paid. The billing response status is Paid.

The buyer can also indicate the date on which the payment was made using the effectiveDate property in the billing response metadata.

"issueDate": "2019-11-20",
"status": "Paid",
"effectiveDate": "2019-11-19"

Updated about 1 month ago