Value: Taxes (VAT)

[timgdavies]

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:

• taxesIncluded - with a codelist initially including only VAT
• taxRate - for a value covering the total effective tax rate

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.

[myroslav]

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?

[timgdavies]

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)

[myroslav]

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. 👍

[JachymHercher]

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)"?)

[jskuhrovec]

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.

[timgdavies]

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"
        }
      }
    }
  }
}

[jskuhrovec]

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.

[timgdavies]

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.

[timgdavies]

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.

[jpmckinney]

Noting that this comes up at every training I've co-facilitated so far (Kiev, Tbilisi).

[antonioherrera]

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).

[timgdavies]

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.

[timgdavies]

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.

[antonioherrera]

@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?

[yolile]

INAI published a repository for this extension: https://github.com/INAImexico/ocds_taxes_extension

cc @antonioherrera

[jpmckinney]

Note: Ukraine also has a VAT extension: https://github.com/openprocurement/ocds_valueAddedTax_extension

[jpmckinney]

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 of value.

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:

1. It seems that having amounts sometimes include tax and sometimes not leads to comparability issues – whether this is indicated by a boolean or not.
2. It seems undesirable for one field to change the semantics of another field, if it can be avoided. It adds extra complexity to interpreting a value, if you need to look at another value each time.

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: #112 (comment)

I'll create a new issue regarding the definition of the existing field.

[antonioherrera]

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.

[jpmckinney]

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.

[jpmckinney]

Closing this issue in favor of #817, which discusses the main points of this issue.