Closed timgdavies closed 4 years ago
Are there any jurisdictions where tax is not fraction of the value, but fixed amount? What about "staged" rates, when rate depend upon the amount?
This is a very good question, and one we can consult on.
I did try to define taxRate
quite carefully as ' the total effective tax rate', so assuming a relevant tax existed which was staggered depending on overall contract value, taxRate should include the average tax rate.
I thought this offered a compromise between modelling complexity, and giving users information they can use to evaluate the tax being paid in a contract.
(e.g. same as effective tax rate for income tax)
The proposed scenario will work for VAT in Ukraine, but won't work for some other taxes (thankfully they are not used in procurement). However even the fact that it's is "effective" rate can complicate the process, since we are capturing change of Value
through tendering process (including Bid in interactive auction). It would be extra challenge to have complex "staging" rules for effective tax calculation within interactive auction. Nevertheless the proposal is good enough to cover the ProZorro case. :+1:
In EU forms, historically, we used to have values, indications of whether VAT is included or not, and the VAT rate. Currently we collect only VAT-free values, because the previous approach seemed to be confusing to users.
Basic question - can I ask for some more use cases when it's useful to know both the VAT-free value and the VAT-included value? Comparability could be reached by only being interested in the VAT-free value. I guess this is mainly for the comparison of final spending between countries with different VAT rates as well as comparison with other data sets, e.g. budgets?
(Tim, are you sure that "It should be possible to calculate the contract value net of tax by dividing amount by taxRate" is correct? Shouldn't it be "It should be possible to calculate the contract value net of tax by multiplying value by (1-taxRate)"?)
I am afraid that ambition for covering even other taxes beyond VAT may lead to very tedious and complex solutions (which will possibly not be consistently grasped by different publishing authorities anyways). Also in my personal experience I see little value of use even of the data on VAT.
Thus I agree with Jachym - publishing prices without VAT seems good enough in terms of comparability and simplicity.
The approach proposed by colleagues in Ukraine is a simple 'valueAddedTaxIncluded' field as follows (json merge patch example):
{
"definitions": {
"Value": {
"properties": {
"valueAddedTaxIncluded": {
"type": "boolean",
"description": "A true/false field to indicate whether the value tax was included"
}
}
}
}
}
I would suggest VAT to include also the tax rate - so that one can calculate the value without VAT. To have numbers comparable with other tenders.
An implementation in Moldova has advised us that law requires both the with and without tax figures to be published.
In this case, the proposal is to extend value
with amountNet
property.
This would give:
"value": {
"currency":"USD",
"amount":96,
"amountNet":80
}
This could be combined with the taxesIncluded
or valueAddedTaxIncluded
proposal above.
Any views on the label amountNet
are welcome.
This was left out of 1.1 on grounds of available time, and as it will be possible to add as a community extension at a later date.
Noting that this comes up at every training I've co-facilitated so far (Kiev, Tbilisi).
Hello guys!
I'm confused about the value that is captured in the amountNet
field. Is it the amount without taxes? Because I can see in the example the amountNet
value is lower than the amount
field. However, at least in Mexico, we use to define it as the total value of one item (with taxes included).
Here, amountNet
was proposed as amount without taxes - as it is common in UK to talk of an amount net of taxes. But reviewing definitions I see net is often used differently.
Will think about terminology here and come back with updated proposals.
From discussion at EBRD workshop today, there is a clear view that valueAddedTaxIncluded
can be included without substantially altering the meaning of value
.
The validator could/should raise a warning when the valueAddedTaxIncuded
field is not present to highlight that without this field data has some ambiguity and will be difficult for some use-cases.
@timgdavies I understand that this field, according to schema.org, is Boolean, but at least in the implementations that we are trying to do in Mexico, we need a way to capture the values with and without taxes. Can we do it with the amountNet field without the ambiguity that it suppose?
INAI published a repository for this extension: https://github.com/INAImexico/ocds_taxes_extension
cc @antonioherrera
Note: Ukraine also has a VAT extension: https://github.com/openprocurement/ocds_valueAddedTax_extension
https://github.com/openprocurement/ocds_valueAddedTax_extension adds Value.valueAddedTaxIncluded (boolean) (same as the Schema.org property).
https://github.com/INAImexico/ocds_taxes_extension adds Value.netAmount (string, integer).
Going through earlier discussion:
From discussion at EBRD workshop today, there is a clear view that
valueAddedTaxIncluded
can be included without substantially altering the meaning ofvalue
.
I tried to find relevant notes (searching for "vat", "tax" and "taxes") in the event's folder, but there is no documented explanation for this view. Without having participated in that table at the workshop:
It seems preferable to have, like in the EU, only tax-free (net) amounts in the OCDS field (for the reasons discussed), and to offer other amounts with VAT included in separate fields.
However, the INAImexico extension uses the OCDS field for the gross amount, and a new field for the net amount.
A minimal new proposal would be to start recommending tax-free (net) amounts for the existing field, and to add amountGross
to the Value
object. However, amountGross
on its own wouldn't satisfy the use cases described by @AlCollier in this comment: https://github.com/open-contracting/standard/issues/112#issuecomment-62322975
I'll create a new issue regarding the definition of the existing field.
It is strange to have the tax-free (net) amount in the OCDS field, because it does not seem to fit well with the current descriptions of the values objects.
For example, the tender/value
has the following description:
The total upper estimated value of the procurement. A negative value indicates that the contracting process may involve payments from the supplier to the buyer (commonly used in concession contracts).
In the case of award/value
we have:
The total value of this award. In the case of a framework contract this may be the total estimated lifetime value, or maximum value, of the agreement. There may be more than one award per procurement. A negative value indicates that the award may involve payments from the supplier to the buyer (commonly used in concession contracts).
For me, when referring the total value of an award or contract we are talking about the gross, then the total value of something.
I think we should discuss this as part of #817. The present definitions are vague, as the "total" can also mean "the total of all lots" or "the total of all items". In the EU, for example, there is an element named "Estimated total value", which excludes VAT.
What we know for sure is that some use cases require the net amount, others require the gross amount, and others require more detail on which taxes are included and recoverable and at what rate. Before we add a field like amountNet
or amountGross
, we need to establish what amount
means on the Value object in #817, since the presence of amountNet
would imply that amount
is gross, and the presence of amountGross
would imply that amount
is net.
Closing this issue in favor of #817, which discusses the main points of this issue.
This issue is under consideration for an extension in version 1.1 of OCDS.
This builds on issue #112
The issue
Our current approach to amounts does not capture whether values are inclusive or exclusive of taxes such as VAT.
At the tender stage a procuring entity will know whether the goods or services being procured are subject to VAT, but not whether the supplier will charge VAT (or other taxes). They may or may not be able to claim back the tax.
At the award or contract stage, the procuring entity will know whether the contract includes tax or not.
Taxes may change over the course of a contract, affecting the total value paid, if taxes are passed onto the buyer.
The proposal
A tax extension which will introduce the following fields to value:
It should be possible to calculate the contract value net of tax by dividing amount by taxRate.
If this extension meets clear user need, it could be considered for adoption into core in a future version.
Engagement
Please indicate support or opposition for this proposal using the +1 / -1 buttons or a comment. If opposing the proposal, please give clear justifications, and where possible, make an alternative proposals.