Closed nickevansuk closed 4 years ago
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.
+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.
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:
vatAmount: 123
instead of vatRate: 0.1384
"valueAddedTaxIncluded": true
)? And do we need to specify the total amount of VAT included included in that?applicableRegion
and exemptRegions
? How do we ensure this can be easily extended internationally?Summarising my understanding of the discusssion, it looks like calculating tax requires some understanding of the following
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:
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!
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
Talking to an accountant regarding the above, the discussion is summarised as follows:
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:
PriceSpecification
as TaxChargeSpecification
and add "lineItems
" property to Order
to include an array of PriceSpecificationOrderItem
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:
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."
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.
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.
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:
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.