Include Tax

[nickevansuk]

The spec needs to include tax.

Schema.org

Schema.org currently doesn't handle tax, though there is a good discussion on the subject here: https://github.com/schemaorg/schemaorg/issues/380

Feedback from Google Reserve comparison

Google Reserve assigns a "tax rate", which is defined as:

A tax rate applied when charging the user for a service, and which can be set on either a per merchant, or per service basis. A tax rate in millionths of one percent, effectively giving 6 decimals of precision. For example, if the tax rate is 7.253%, this field should be set to 7253000. If this field is left unset or set to 0, the total price charged to a user for any service provided by this merchant is the exact price specified by Service.price. The service price is assumed to be exempt from or already inclusive of applicable taxes. Taxes will not be shown to the user as a separate line item. If this field is set to any nonzero value, the total price charged to a user for any service provided by this merchant will include the service price plus the tax assessed using the tax rate provided here. Fractions of the smallest currency unit (for example, fractions of one cent) will be rounded using nearest even rounding. Taxes will be shown to the user as a separate line item.

Feedback from Legend

[In the current spec] there is no mention of VAT (or sales tax). Classes and activities [in Legend] can be subject to VAT or not depending on a number of things including the status of the operator. Each of our inventory items has an associated tax code. If we create a basket item internally, then we hand Tax all the way through and the operator will forward this to the Tax Man. And perhaps the broker will as well.

Equally, we may need to include any tax in the offer. It may be that all the items we deal with are not taxable, in which case there is no issue, but I don't think the standard caters for it if there is.

[iaindowns]

The other thing I'm not entirely clear on is the role of the broker and how that affects the tax. Or worse the role of the organisation that is brokered to (with the broker as an intermediary).

This is well outside my skill set, but I think there is a distinction between the 3rd party being an agent and being a reseller and this may affect if the tax is due from the aggregator or the operator.

It seems to me we may need to get some professional advice on the options here.

[nickevansuk]

+1 for getting professional advice sounds like a great plan

We've got some rough guidance informally from last year, see below:

At this stage we have only sought informal advice in order to clarify and understand the relative risk of the VAT issue. We will be looking to seek formal advice on the matter if required by the OpenActive community, but the below serves as an informal summary to hopefully allay any fears in the near term.

Based on an informal consultation with a tax specialist from KPMG (it was not part of a paid consultation), for third party facilitated transactions on open data, as long as the third party is clearly distinguished as the disclosing agent, and the leisure operator remains the principal agent, then the third party is just an introducer/facilitator and therefore it should not affect the tax situation for the principal agent (i.e. the operator) as they remain the seller of the goods to a customer. Provided that a third party clearly indicates that this is the situation during the customer flow (i.e. customer is aware they are buying from the operator, not the third party), as well as laying this out within their T&Cs, it should not be a problem.

Misunderstanding might arise for those thinking of the third party as a “re-seller” of the activity, which would incur VAT implications, but so long as the third party never becomes the principal agent, the underlying goods (i.e. the activity session) should not attract any different tax implications than if it were sold directly from the operator’s own website.

[nickevansuk]

For any professionals that get signposted here: The above is worth a read, including the link to the schema.org discussion at the very top.

To summarise the key outstanding questions where we would appreciate professional advice:

• Clarifying whether brokers are an agent or a reseller, and whether that affects the way we represent VAT for items of the order, and the order total.
• Help us to understand whether we should use VAT rates (as Google Reserve does) or VAT sums in the specification when representing the tax component of the receipt i.e. vatAmount: 123 instead of vatRate: 0.1384
• What fields do we need to represent tax on the receipt and in the order "basket" before the user confirms payment, e.g.:
  • A total "inc VAT" or a total "ex VAT". Does it need to be specified what the total represents (e.g. "valueAddedTaxIncluded": true)? And do we need to specify the total amount of VAT included included in that?
  • The region / country within which the VAT is payable. Do we need applicableRegion and exemptRegions? How do we ensure this can be easily extended internationally?
  • If there is a VAT exemption (e.g. some providers are charities) do we need include this information
• When are we required to display VAT data, at the point of checkout, at the point of receipt, for each session advertised in the feed, etc

[ldodds]

Summarising my understanding of the discusssion, it looks like calculating tax requires some understanding of the following

1. the role of the broker (e.g agent vs reseller)
2. the operator
3. the location of the user, e.g. whether VAT is applicable
4. the applicable VAT rates in different regions
5. and, I think, VAT registration status of the user (e.g. if I'm booking on behalf of a small business, in which case API may need to collect my VAT number?)

I think that most of this, apart from possibly the requirement around (5) is outside the scope of the specification?

We don't need to be defining how and when tax is calculated, current rates, how VAT is collected and reported, etc.

Whether a broker might be classed as an agent or reseller is part of their arrangement with the platform for using the API is outside scope of the specification. The same is also true for how tax is handled as part of any revenue share agreements.

In my view, I think our focus should be on ensuring that its clear whether prices are inclusive or exclusive from VAT (this might be mandated, or could be advertised separately in the API), so that a broker can trigger appropriate calculations.

I think I'd also lean towards communicating the total VAT amount for individual items and the overall order, rather than individual rates.

I'd suggest that we do some additional work here to move this proposal forward:

• seek some expert opinion, I think this has been offered by the community? A short meeting might help clarify some questions
• review how other APIs are handling tax, so we have points of comparison. we can do this by looking at other ecommerce APIs as well as the booking systems in the community

[nickevansuk]

Great feedback @ldodds, so as a starter for 10 based on the above:

valueAddedTaxIncluded already exists in schema.org

Assuming that VAT only needs to be displayed at the time of purchase, and that it is not affected by the region of the buyer (i.e. it is fixed for each seller), we simply need valueAddedTaxAmount and valueAddedTaxIncluded as below (noting @RichardWallis's point about minPrice and maxPrice inconsistency: https://github.com/schemaorg/schemaorg/issues/380#issuecomment-328895000):

"partOfInvoice": {
  "type": "Invoice",
  "paymentStatus": "PaymentDue",
  "totalPaymentDue": {
      "type": "PriceSpecification",
      "price": 10.00,
      "priceCurrency": "GBP",
      "valueAddedTaxAmount": 2.00,
      "valueAddedTaxIncluded": true
  }
},

If VAT also needs to be displayed in Offers, we also need valueAddedTaxAmount and valueAddedTaxIncluded included in Offer as below:

"offers": {
  "type": "Offer",
  "validThrough": "2018-10-29T11:00:00Z",
  "validFrom": "2018-10-01T11:00:00Z",
  "description": "Winger space for Speedball.",
  "id": "https://example.com/offers/1234",
  "name": "Speedball winger position",
  "price": 10.00,
  "priceCurrency": "GBP",
  "isCancellable": true,
  "cancellationValidUntil": "2018-10-28T11:00:00Z",
  "valueAddedTaxAmount": 2.00,
  "valueAddedTaxIncluded": true
}

We have an expert call on Tuesday to discuss this, which I'll report back on here. If anyone in the community is interested in offering to review other APIs that would also be great!

[iaindowns]

Can you also consider other localities?

In much of the world (e.g. North America) prices are typically shown to the customer Net of tax and tax added in the basket. Further there can be more than one type of tax. In North America, for example, there are separate tax lines for federal and state taxes and there can be additional specialist sales tax (alcohol tax is an example, though perhaps not directly pertinent).

I believe that there is a requirement to show a tax breakdown and that could mean separating out the different rates of tax (in the UK, 20%, 0% and exempt) on the receipt. I’m less sure on that, but I think the API needs to include that level of data even if it’s not displayed.

Iain

[nickevansuk]

Talking to an accountant regarding the above, the discussion is summarised as follows:

• Tax is only required to be shown at the point of receipt (and in some cases a VAT receipt may be requested out-of-band from the purchase process itself).
• A number of different taxes can apply in different international locations, though VAT is the only one that applies to the UK.
• It’s a nice-to-have to present VAT rates at the point of purchase to the customer, not a requirement.
• EU-to-EU business transactions can incur 0% tax, so in some scenarios the tax % can vary based on the buyer.

Further research has shown that there are companies that specialise in calculating tax rates, such as Avalara, TaxJar, and Taxamo, which take into account the customer’s country or U.S. state, the types of products being purchased, and the order total.

Through the call with the accountant, and looking at Stripe’s API (https://stripe.com/docs/orders/tax-integration) and Shopify's API (https://help.shopify.com/en/api/reference/orders/order), it became apparent that the following proposal would be the most straightforward:

• Allow arbitrary tax line items. Such tax line items have a name and price, not a rate (though rate could be included, it seems from other APIs like a nice-to-have?). This can be achieved via either:

  • Subclass PriceSpecification as TaxChargeSpecification and add "lineItems" property to Order to include an array of PriceSpecification
  • Subclass OrderItem to include type TaxOrderItem, and allow OrderItems to have a priceSpecification associated with each. These can be included in the response to the OrderQuote and in the returned Order itself.

• This allows multiple tax lines to be added to the order, and does not restrict the specification to a particular type of tax or number of taxes. It also allows for systems that support EU-to-EU business transactions to dynamically change the tax lines accordingly.

• This has also raised the point that the buyer may be an Organisation (as many of MyLocalPitch’s customers are), as well as a Person. To this end the customer in the Order should include either:

  • Organization
  • Person

• This provides an extension point for initiating the 0% calculation for EU-to-EU arrangements (e.g via the vatID in the Organization or the Organization's location), support for which can be added to the specification in the future. This leaves room for the use of the spec to evolve for those booking systems and brokers that choose to recognise and process additional properties within the Organization, while remaining backwards compatible with this version.

• Finally this proposal does not include any changes to “Offer”, as including the tax breakdown of an offer is a nice-to-have, and we likely need to have clearer usecases around B2B sales to make the most of this.

• We recommend that all prices presented in Offer are assumed to be a value that the user will expect to see based on local conventions of the seller (i.e. for the UK these always include tax). We also note that Schema.org already allows Offers to include a priceSpecification which can include the property “valueAddedTaxIncluded”, and that this may be used to state explicitly gross or net prices for an Offer.

• As the price / priceSpecification within the Offer are not required for the proposed OrderQuote and Order process (only the ID of the offer is required), and as the resulting line items from the OrderQuote and Order may contain tax items (as above) independently of the price / priceSpecification, this proposal states that the price / priceSpecification of the Offer is for guidance only, and that the totalPaymentDue of the OrderQuote or Order should always be used for the booking and payment process.

• We should use PriceSpecification instead of MonetaryAmount for totalPaymentDue, as schema.org says “it is recommended to use PriceSpecification Types to describe the price of an Offer, Invoice, etc."

[nickevansuk]

Draft idea: OrderItem includes a property taxItem: subclass PriceSpecification as TaxChargeSpecification and add "lineItems" property to Order to include an array of PriceSpecification Subclass OrderItem to include type TaxOrderItem, and allow OrderItems to have a priceSpecification associated with each. These can be included in the response to the OrderQuote and in the returned Order itself.

[nickevansuk]

All points of this issue are now comprehensively covered within the current specification, noting that additionally:

Due to the different rounding errors introduced by different approaches to calculating tax, both the OrderItem level tax calculations, and the overall tax calculation for the Order, are handled by the Booking System. The Broker does not do any arithmetic.