What is TaxCloud's policy regarding Transaction import timing?
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 the tax amount due. This document will explain how TaxCloud treats your transaction data as it relates to our date/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 the 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, does 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 than 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.
If you have any questions, please do not hesitate to email us at service@taxcloud.com