NOTE: Blog updated to reflect release date, changes are available in sandbox now.
============================================================
Changes to US sales tax business logic for Quickbooks Online API coming soon (August 10, 2018). This change impacts only AST enabled compnies for sales transaction lines that do not contain a TaxCodeRef.
With this change, when a sales transaction line does not explicitly specify a TaxCodeRef, we will be treating that line as if the TaxCodeRef is TAX and we will determine the taxability of that line based on the item’s taxability.
This is different from the current behavior in which an empty TaxCodeRef is considered to be equivalent to a NON TaxCodeRef.
Description
An earlier blog tells how the Automated Sales Tax (AST) engine looks for a tax intent by inspecting the sales transaction payload for the TxnTaxDetail section, among others, to determine whether or not to apply sales tax. This blog outlines some of the other ways in which the tax intent is derived going forward.
Note: Every app has unique use cases and uses our APIs differently. There is a chance that this change might impact your application and therefore warrant a code change. We request that you review the details below and let us know if you need further assistance.
The QuickBooks Online vision of AST is for the QuickBooks Online platform to take up the responsibility of applying the right taxes on a transaction. Aligned with that vision, and aligned with QuickBooks Desktop SDK behaviors that are in place, we are tweaking the default behavior of the QuickBooks Online API to apply taxes in the same way the UI would. That is, to apply them based on the following criteria unless explicitly directed not to do so.
- The taxability of the customer in question.
- The address of record for the transaction. This is usually the shipping address, but possibly the business’ address or the location address.
- The taxability of the items for the agencies that apply to the address of record.
The way to explicitly direct the Tax Engine not to apply taxes on a transaction or any of its lines, is to explicitly indicate NON against such lines.
The table below illustrates this change in behavior. For the sake of brevity, the Sample Payload column refers to lines in terms of the value mentioned against TaxCodeRef.
| # | Scenario | Sample Payload | Existing Behavior | New Behavior |
| 1 | All Line Items are explicitly marked taxable. | Line 1 – TAX
Line 2 – TAX Line 3 – TAX |
Not taxed (see preceding paragraph). | All lines are be taxed. |
| 2 | All Items are explicitly marked non-taxable. | Line 1 – NON
Line 2 – NON Line 3 – NON |
Not taxed. | Not taxed. |
| 3 | No Items have taxability Information against them. | Line 1 – NULL
Line 2 – NULL Line 3 – NULL |
Not taxed. | The taxability of each line’s item is applied to the taxability of that line. |
| 4 | Combination of taxable and non-taxable lines. | Line 1 – NON
Line 2 – NON Line 3 – TAX |
Not taxed. | The 3rd line is Taxed based on the line Item’s taxability. The first two does not have line taxability applied based on the item. Note that this may affect e-filing later as the user would be required to specify a reason a given sales line was not taxed. |
| 5 | Combination of non-taxable lines and lines without taxability information. | Line 1 – NULL
Line 2 – NULL Line 3 – NON |
Not taxed. | The first two has the taxability of the item referenced applied to the taxability of the line.
The 3rd line is NOT taxed, overriding any decisions that the tax engine may make. |
| 6 | Combination of taxable lines and lines without taxability information. | Line 1 – NULL
Line 2 – NULL Line 3 – TAX |
Not taxed. | All three lines have the item’s tax rules applied. |
| 7 | Combination of taxable and ton-taxable and tines that do not have taxability specified | Line 1 – TAX
Line 2 – NON Line 3 – NULL |
Not taxed. | The first and third line has the item’s tax rules applied.
The second line is not taxed. |
Note: In talking about the current and new behavior, this table assumes that the TxnTaxDetail element (transaction-level tax) is omitted from the transaction’s payload. The existing behavior therefore is not taxed for all scenarios, since the absence of that section in any part is currently interpreted as an intent to not apply any tax.
It should be evident from the above table, that if you’d like the Tax engine to NOT apply taxes against any line item, such lines need to explicitly marked NON in the TaxCodeRef section.
There are three ways in which tax can be explicitly mentioned at the line level for a sales transaction today:
- TaxCodeRef specifying TAX.
- TaxCodeRef specifying NON.
- Omit the TaxCodeRef element completely
To illustrate this with an example, consider the following payload with three lines:
…
“Line”: [
{
“Amount”: 120,
“Description”: “Graphic Tees”,
“DetailType”: “SalesItemLineDetail”,
“SalesItemLineDetail”: {
“ItemRef”: {
“value”: “5”
},
“TaxCodeRef”: {
“value”: “TAX”
}
}
},
{
“Amount”: 200,
“Description”: “The Magic of Math”,
“DetailType”: “SalesItemLineDetail”,
“SalesItemLineDetail”: {
“ItemRef”: {
“value”: “3”
},
“TaxCodeRef”: {
“value”: “NON”
}
}
},
{
“Amount”: 240,
“Description”: “Whiteboard Markers”,
“DetailType”: “SalesItemLineDetail”,
“SalesItemLineDetail”: {
“ItemRef”: {
“value”: “4”
}
}
}
…
This payload includes three line items, the first is marked taxable, the second is marked non-taxable and the third omits the TaxCodeRef section altogether. In the table above where various scenarios are outlined, the case above maps to # 7.
Leave a Reply