TaxCloud Time Resolution Policy
TaxCloud Time Resolution Policy
When you send transaction information to TaxCloud using TaxCloud’s APIs, or upload transaction data to TaxCloud via the transaction uploader UI, TaxCloud relies upon international standards to correctly stamp the date and time of each transaction. As a sales tax calculation and remittance engine, date information describing when a transaction has been captured or shipped is necessary to properly calculate and remit tax amount due. This document will explain how TaxCloud treats your transaction data as it relates to our date and time recognition policy and provide examples of how this impacts you.
1. TaxCloud Uses UTC time
Universal Time Coordinated (UTC) is a global standard for recording time. The key component of this standard is global agreement on which timezone represents a zero offset and coordination with every timezone for their particular offset from UTC. For instance, Eastern Daylight Time (EDT) is 4 hours behind UTC time, which can be noted as UTC -4. Accordingly, 1 June 2019 00:00 at UTC 0 is equivalent to 31 May 2019 20:00 at UTC -4.
2. How does this affect transactions via the API?
When TaxCloud receives a call to its API, any date information is adjusted to UTC time. For example, a call to authorize a transaction on June 5th, 2019 at 11:19 AM EDT would be saved as 2019-06-05 15:19 UTC 0 in the TaxCloud database. More importantly, a call to authorize a transaction on June 30, 2019, at 8:00 PM EDT will be saved as 2019-07-01 UTC 0. Please note the change in month.
3. How does that affect a transaction via CSV upload or Marketplace Sync?
CSV uploads have relevant transaction dates comprised of a year, month and day that are concatenated together to form a single integer value. For example, June 30, 2019 would be represented as 20190630. The first four digits represent the year (2019), the second two digits represent the month (06), and the last two digits represent the day (30). When uploaded, the implied UTC offset will be zero. This means it will be recorded as already being in UTC format and saved as 2019-06-30 00:00 in our database. Note that there isn’t a time component for the TransactionDate column.
Authorized, Captured and ShippingDate information, on the other hand, do have a time component. As such, these date/time fields will go through UTC resolution during data ingesting in order to be recorded in TaxCloud as UTC 0. Using our previous date of June 30th, 2019, if the ShippingDate is at 7PM EDT, then the taxable date will be 2019-06-30 23:00 in our database. Still in June.
However, if the ShippingDate is at 9PM EDT, then the taxable date for the transaction will be 2019-07-01 01:00. Now in July. This is important as state tax rates for July will also be applied. So, even though the transaction may have shipped on June 30th at 9PM in New York, for the purposes of recognizing the tax event, it will be recorded as July 1.
NOTE -- the time resolution is to the nearest minute. If the time value has seconds less then 30, then the time will round down to the nearest minute. If the time value has seconds equal to or greater than 30, then the time will round up to the nearest minute.
4. Why should I care about any of this?
The states expect us to store dates as UTC dates and apply the transition between months as described above. As a result, API based transactions with timestamps on or after 8:00 PM (EDT) on the final day of the month will be stored as the first day of the following month by TaxCloud. Similarly, CSV Upload based transactions with any timestamps on or after 8:00 PM (EDT) on the final day of the month will also be recognized as taking place on the first day of the following month and stored as such as a UTC date. Though this can be surprising, the logic is consistent, agreed upon globally and expected so merchants should plan on it.
5. A note for Amazon Sellers
Amazon reports favor a reconciliation event that can place multiple transactions as having occurred at precisely midnight at UTC 0. However unlikely it may be that tens, hundreds, or even thousands of transactions happened at this very pivotal moment, we have decided to use that datetime as the record date for taxation purposes. For example, Amazon may have 10 transactions in a sales report stating a Shipment_Date of 2019-07-01+00:00. Previously, our uploader had interpreted these transactions as having been in the month prior based on realistic likelihood. Moving forward we will accept the literal UTC 0 declaration and recognize the event in the declared month—July 1st, 2019 at precisely midnight UTC 0. Accordingly, clients who incurred late fees for March 2019 or April 2019 periods based solely on this scenario will be issued refunds by TaxCloud as we adjust to Amazon’s reporting idiosyncrasy.
If you have any questions, please do not hesitate to email us at firstname.lastname@example.org.