Receipts vs Invoices

[nickevansuk]

The specification does not distinguish between Receipts and Invoices, and should provide clearer guidance around VAT Receipt generation

Also address:

In the VAT invoice, we need to include the amount payable excluding VAT, but we cannot calculate this amount (for TaxGross Sellers - i.e. all of the UK) as we cannot calculate tax (https://openactive.io/open-booking-api/EditorsDraft/1.0CR3/#x10-1-14-oa-taxchargespecification:~:text=The%20Broker%20must%20not%20attempt%20to%20perform%20any%20tax%20calculations,-.)

[nickevansuk]

7.2 Invoices and Tax receipts For each successful booking operation, the Broker must generate a new Invoice in the form of a tax receipt

See here for a clear breakdown of the different concepts: https://www.zoho.com/invoice/guides/invoice-vs-bill-vs-receipt-a-detailed-comparison.html

Currently the specification describes "Invoice Generation" as generating a new "Invoice" in the form of a "tax receipt". This has the potential to cause confusion.

For example, the HMRC guidance refers to "VAT Invoices" and "sales vouchers" (https://www.gov.uk/guidance/vat-guide-notice-700#retailers-vat-invoices):

If you make retail sales, you should give your customer a VAT invoice if asked for one. You may be liable to a financial penalty if you do not issue a VAT invoice when asked to do so by a taxable person. If you accept card payments, you may adapt the sales voucher you give to the cardholder at the time of the sale to serve as a retailers’ VAT invoice. If you issue an invoice or receipt in addition to the card voucher, only one of the documents may be in the form of a VAT invoice.

In the above it is clear that the primary purpose of the document is a "VAT invoice" (whether it is an invoice that also serves as a receipt, or a repurposed receipt/sales voucher that is also an invoice), therefore it would likely to clearer to label these "tax invoices that may also serve as receipts" in the specification rather than "Invoices in the form of tax receipts".

The Broker may choose to provide a separate receipt for the card payment (e.g. the default Stripe email receipt), however this is separate from "VAT invoice", as it does not contain tax details. The specification is primarily concerned with the VAT invoice (legally required) rather than the receipt (optional).

Design guidance should be provided for brokers that looking to create "tax invoices that may also serve as receipts" (e.g. a "Paid" stamp in the top right corner, or with a "Less amount paid" line at the bottom of the invoice that brings the total due to zero). A range of examples of VAT invoices that are also receipts are provided below, and could be included in such guidance:

• Zoom
• Xero
• Manychat
• Make
• Leon
• Huckletree
• Atlassian

Additionally it is possible that a Broker may prefer to issue a "Credit Note" for any partial refund on the invoice, which may also serve as a receipt for this partial refund, instead of reissuing the invoice. Issuing a credit note may be necessary if the invoice also serves as a receipt, as it may not be appropriate to regenerate an invoice that also serves as a detailed receipt. This conflicts with current spec ("A new Invoice must be generated for the Order to replace the previous Invoice on each occasion that a set of orderItems within an Order are cancelled") as the "Invoice" is in the form of a "tax receipt". The credit note approach actually aligns with the existing model for Payment, where a single "Payment" is associated with multiple "Refunds". In this new suggested model, Invoice and Payment have a 1:1 mapping, and Credit Note and Refund have a 1:1 mapping. The specification should therefore be updated to suggest that Credit Notes should or may be used - as they appear to be a best practice approach to recording refunds.

Credit notes are also tax documents, and must include:

• The same details as the original invoice to which they refer
• Sufficient information to identify the original invoice
• More details for UK Credit Notes can be found in the "Valid credit notes" section here.

It is important to note that credit notes as described above are issued by the Broker. From the Booking System and Seller's perspective the refund has been issued, and the above suggestion does not permit Booking Systems / Sellers to retain credit on Customer's accounts for bookings made via the Open Booking API, which are guest bookings (unless bookings are made via the Customer Accounts API, which are bookings on account).

All of the above implies two concrete alternative approaches, that perhaps should be included in the guidance (or the spec itself):

1. Invoice Regeneration: Generate a tax invoice upon a successful B call, and regenerate the tax invoice at each cancellation so that it remains accurate, implicitly voiding the previous invoices; separately, provide receipts for payments and refunds (such as the default Stripe payment and refund email receipts)
   • Invoices and receipts are separate documents (though a single invoice document could be marked as "Paid" and include refunded items to also serve as a very basic receipt)
   • Closest to the "regeneration" approach of the current spec
   • Likely adequate for Business-to-Consumer, but not adequate for Business-to-Business
   • "Regeneration" allows a consumer to get an up-to-date VAT invoice, which is their legal right, but is not sufficient for B2B (as it would likely not play well with accounting systems), and therefore the storing of previous versions of regenerated invoices is unnecessary.
   • Simple to implement (e.g with Stripe)
2. Invoices and Credit Notes: Generate a tax invoice that also serves as a payment receipt upon a successful B call, and issue a Credit Note that also serves as a refund receipt for each cancellation.
   • Invoices and receipts are combined into one document
   • Best practice
   • Suitable for B2C and B2B
   • Requires more work to implement

Note these suggested changes only impact Brokers that have implemented this specification, and do not impact Booking Systems.

Additionally perhaps guidance (outside of the spec) should be provided for the diagram referenced in "7.1 Roles and responsibilities overview", for Brokers that want to represent these concepts internally using JSON-LD, e.g:

1. Invoice Regeneration

{
  "@type": "Order",
  ...
  "partOfInvoice": {
    "@type": "Invoice",
    "url": "https://example.com/invoice/1233" // Latest regenerated tax invoice; *not* a payment receipt (though could be a "paid" invoice)
  }
}

2. Invoices and Credit Notes

{
  "@type": "Order",
  ...
  "partOfInvoice": {
    "@type": "Invoice",
    "url": "https://example.com/invoice/1233", // Tax invoice that may also serve as a payment receipt
    "referencedByCreditNote": [ // Array of credit notes that may also serve as refund receipts, one for each partial refund
      {
        "@type": "CreditNote",
        "url": "https://example.com/credit-note/1233" // Credit note that may also serve as a refund receipt
      }
    ]
  }
}

[nathansalter]

This is an interesting question, as I can imagine several workflows (such as exists with Playfinder) where the entity you are dealing with is explicitly Playfinder (the Broker) rather than the Bookteq Account (Booking System). In this case it would seem to be difficult to fully encapsulate the relationship between the two entities and Invoice generation (as in our case) is not always necessary.

In the case where you're interacting directly with the Booking System via the Broker, a Receipt or Invoice at B seems like a decent approach, regenerating when order changes happen. I fully believe however that this should be downgraded from a MUST to a SHOULD or RECOMMENDED, as it won't always be required.