Skip to main content

Legal

Tax & Accounting

Trade & Supply

Risk & Fraud

News & Media

Books

Developers

Transactions

Reverse transactions

A reversal can either be initiated by the customer, Thomson Reuters, or an issuing bank, and could be the result of a transaction being refunded (for example, items returned at a store after purchase), or anything else between the merchant and their customer that could result in a change to the original transaction.

Reverse transaction after 2-year period

Beginning April 15, 2025, ONESOURCE Determination will perform a reverse transaction using only the 1st 2 years from the previous invoice date. If the system initiates a reverse transaction within this timeframe, it will process the reversal according to the reverse transaction logic. However, if someone attempts a reverse transaction after the 2-year period, Determination won’t reverse the previous transaction.

Reverse transactions overview

To follow the process of double-entry systems where transactions are recorded as debits or credits, in an ideal scenario, the deletion of transactions must be handled with reversals of the original transaction rather than deletion. In that respect, transactions or Invoices processed by the systems (Enterprise Determination Cloud & Determination Anywhere (DA)) are never deleted. So, for the reasons for a transaction to be reversed, a credit memo matched to an existing invoice should be created.
The following constitute mandatory attributes to be included in the customer transactional system (source system) request to the ONESOURCE Determination tax engine to calculate the taxes:
Mandatory attributes
Mandatory elements (JSON / XML)
Description
callingSystemNumber / calling_system_number
A descriptor of the calling (source) system sending the transaction.
companyName / external_company_id
The identifier used by companies when calling Determination. This element tells Determination which company is calling it, letting Determination to use the correct company-specific settings.
companyRole / merchant_role
The role the company plays in each transaction: B for Buyer, M for mediator, S for Seller.
documentNumber / invoice_number
This number is passed through to the audit tables and acts as a reference in the audit tables as well as for credit transactions.
externalCompanyId / external_company_id
The unique identifier used by business application to indicate which company to use in Determination.
hostSystem / host_system
The name of the ERP instance sending the transaction.
documentDate / invoice_date
The date of the invoice or document.
uniqueDocumentNumber / unique_invoice_number
The unique identifier for invoice, as assigned by the ERP system or generated by ONESOURCE Indirect Tax Determination. Note that for the Unrelated Reversal process, the value here can't match with an existing value in the audit database.
merchantId / Merchant_ID
The root tenant UID. The unique identifier to indicate a company to use in Determination.
The following attributes determine the uniqueness of a transaction invoice in the audit database:
  1. HostSystem / Host_System
  2. CallingSystemNumber / Calling_System_number
  3. uniqueInvoiceNumber / Unique_Invoice_Number – In a case where this information is not present in the transaction request, then {ExternalCompanyID|Invoice_Number|Company_Role} is used to create a Unique Invoice Number within the Determination system.
  4. merchantId / Merchant_ID
These 4 attributes are referenced as Unique Key in the following information.

Reversal of transactions

The process of reversal in the system entails the negation of the original transaction that is stored in the audit database, and the subsequent creation of a new record that corresponds to the last request. The reversals can be differentiated as Unrelated Reversals, Implicit Reversals, and Explicit Reversals.
Unrelated Reversals – This is the recommended best practice for reversing a transaction. If the source system creates a reversal/cancellation document, or a record with a separate documentNumber, then the value can be passed as a negative. In this case, the system won't perform a reversal, and both transactions will be independently stated in audit with certain attributes (Original Invoice Number) that can be used to see their relationship.
It's recommended to have reference to the original transaction for this process:
Elements and descriptions
Optional elements
Description
originalDocumentId
The original document ID as shown on the document in the source system. Not used in calculations.
originalDocumentDate
The date of the original transaction. Used in Date Determination Rules.
originalDocumentNumber
This number enables a credit invoice to be associated with an original invoice in the audit tables for reporting purposes.
Implicit Reversal – This process follows the assumption that the source system will pass the Unique Key attributes that lets the data to be matched with an existing record and can help with partial reversals if that's the goal of the transacting system.
If the Unique Key attributes sent to Determination previously exist in Audit, Determination maintains the original record (say, $100.00), creates a reversal of that document, and then creates a new record of that document representing the latest document information passed (say, the new transaction is for $25.00). There will be 3 records in the audit:
  1. Original document 1234, line 1 = $100.00
  2. Determination Reversal document 1234, line 1 = -$100.00
  3. Resubmitted reversal document 1234, line 1 = $25.00
Alternatively, if a transaction is sent with matching Unique Key attributes and a negative amount, there will be 3 records in audit:
  1. Original document 1234, line 1 = $100
  2. Determination Reversal document 1234, line 1 = -$100
  3. Resubmitted reversal document 1234, line 1 = -$100
Explicit Reversal – This process follows the assumption that the source system wants to do a full reversal or to void the original transaction fully.
Determination maintains the original record (say, $100.00), and then creates a new record of that document representing the latest document information passed. There will be 2 records in the audit:
  1. Original document 1234, line 1 = $100.00
  2. Resubmitted reversal document 1234, line 1 = -$100.00
For Explicit Reversals, the entire payload for the request to the tax engine is not required, and only the basic elements are needed to do the reversal.
  1. For transaction requests utilizing Rest, a separate end point needs to be reached. The API documentation is available in the Developer Portal.
  2. For transaction requests utilizing SOAP, the IS_REVERSED flag should be set to TRUE. <IS_REVERSED>true</IS_REVERSED>.
The following diagrams give the high-level transfer of the reversal process for both Enterprise Cloud and Determination Anywhere applications on the OCI & AWS platforms where the audit database resides. AWS is Amazon’s Web Service cloud platform. OCI is Oracle’s Cloud Infrastructure. The Enterprise Cloud Determination application is hosted on both these cloud platforms, with DA server-side components hosted there for DA customers.

Process sequence visualization

It is to be understood that the tax engine itself, whether Enterprise Cloud or DA, doesn’t perform any reversal activities. Instead, an acknowledgement will be returned for the request right away; the reversal is committed asynchronously/offline to the audit database. Customers can validate the transactional records in reports (NGRA). This applies to both SOAP & Rest web service requests on AWS Enterprise Cloud & DA, except in the case of OCI. There is an ETL process that installs the data from the Audit DB to NGRA for reporting purpose.
With Reversals by Enterprise Cloud Determination on the OCI platform, when the source system gets a confirmation of a transaction processed, that entails that the reversal has happened at the same time, that is, actual commit has taken place in the Audit DB.
Therefore, in the case of an explicit reversal, you can expect the following response from the tax engine if a matching invoice doesn’t exist, subsequently the reversal transaction won’t be recorded in the database:
With Reversals by Enterprise Cloud Determination on the AWS platform, the source system will get an acknowledgement that the transaction is processed, but the reversal activity occurs outside of the tax engine, or offline from the tax calculation process.
So, in the case of an explicit reversal, whether a record previously exists or not, and whether a reversal activity has occurred or not later down in the process, the tax engine will respond as:
The transaction that was submitted as a reversal will try to be matched up with its existing invoice. The process will attempt a few times to find the matching invoice in the audit database; if at the end it still can't, the record will be inserted into the audit database. Such records could be identified from reports (NGRA) as follows:
  • User can create Custom report, add Reversal column to template, and get filtered dataset by selecting Reversal = ‘Y’.
  • Additionally, the user can make use of the standard report called US Document Details and get a filtered dataset by selecting the Reversal column as ‘Yes’.
With Reversals on DA, whether AWS or OCI platforms, the source system will get an acknowledgement that the transaction is processed, but the reversal activity occurs outside of the tax engine, or offline from the tax calculation process.
In the case of an explicit reversal, whether a record previously exists or not, and whether a reversal activity has occurred or not later down in the process, the tax engine will respond as:
The transaction that was submitted as a reversal will try to be matched up with its existing invoice. If there is no match found, it will stay in a Failed queue and will have to be looked up manually as an operational process as it doesn’t get inserted into the audit database.
The DA Client doesn't keep a record of historical transactions, since processed transactions are offloaded from the DA Client to the Audit DB as quickly as possible.
In all the previous cases, for an Implicit Reversal process, the success message response noted previously is returned when the tax calculation request has been processed without any errors by the tax engine.

This article applies to:

  • Product: ONESOURCE Determination, ONESOURCE Indirect Tax