How to Manage Tax in SAP Ariba Buying & Invoicing solutions?
As our friend Christopher Bullock (and potential closet SAP Ariba expert) said so bluntly in 1716:
’Tis impossible to be sure of anything but Death and Taxes
Although I’m sure we can fend off the former together for a while still, I am sad to say that if you are implementing Ariba Buying & Invoicing, I won’t be able to help you avoid dealing with the latter. However, there is hope! I’d like to give you an overview of the different options for supporting Input Tax and/or Value Added Tax (VAT) scenarios in the Ariba solutions:
There are typically 3 tax support models for the Ariba Buying and Invoicing modules:
Option 1 – Manage Tax Directly in Ariba via the Integrated Tax Tables
This entails using a set of tax tables maintained directly in the Ariba cloud solution (supported by an integrated CSV file import/export tool). These tax tables can be used in two ways:
1.1 Determine which tax values should be auto-populated on the Purchase Requisition / Purchase Order. The expected tax can therefore be sent to the vendor on order. The Purchase Order tax value is then used for the three-way match when the vendor submits an invoice with tax included. This can be done at the header or line item level.
1.2 Use the tax tables directly for the match against the invoice (no tax needed on the PO) when the vendor submits an invoice with tax. No expected tax is communicated to the vendor.
The advantage of using scenario 1.1 is that it can be used to support “self-assessed” tax scenarios. The requester can change the applicable tax directly on the purchase Requisition. This is usually necessary if the actual usage you will make of a commodity influences the tax treatment. For example, input tax could be different for a material depending on if it is used in production processes or R&D processes).
Scenario 1.2 is simpler from a data flow / structure perspective as the tables are validated directly against the invoice instead of flowing through the Requisition and Purchase Order. However, depending on your business model, you may leave significant amounts on the table if you are not managing tax at the Purchase Order level.
In both these scenarios, when there is a mismatch between the tax in Ariba (PO or table) at invoice receipt, an invoice exception is generated and sent to an error handler via workflow for resolution in Ariba Invoice Management. Once the correct tax is applied by the exception handler, the invoice is sent to your back-end ERP system for posting and payment.
It is important to note that you can only have a single exception handler determined automatically for any invoice exception generated in Ariba Invoice Management, tax or otherwise. Additional handlers need to be populated manually by the first exception handler.
There should be no tax validation configured for Ariba invoices in the back-end ERP as you’ve just dealt with tax management in the Ariba system.
Option 2 – Manage Taxes via an Ariba Invoice Management Tax Add-On
In both variations of option 1 listed above, all the tax data must be maintained manually in the Ariba tax tables by the buying organization. Depending on the size of your operations and the number of countries in which you operate, this may be unfeasible due to the sheer volume of tax rules you need to manage.
This is where an add-on such as Thomson Reuters or Vertex can be integrated to the Ariba solution to remove the need to maintain these tables. The tax add-on companies make it their core business to maintain up-to-date tax tables that can be queried on an “as needed” basis. Therefore, this scenario basically affords the same scenarios as option 1 but with no tax table maintenance needed.
However, these add-ons cannot support the “self-assessed” tax scenario with standard functionality so an enhancement needs to be designed and implemented to capture this process variation. For example, you could add a checkbox in the requisition screen and develop a custom invoice exception to always fire when this checkbox is checked in the PO. This would be the trigger for the tax specialist / accounts payable clerk to manually assign the correct “self-assessed” tax. This indicator could also be fed to the add-on with a custom rule to return the self-assessed tax details if automation is desired.
Otherwise, in standard tax scenarios, when a vendor submits an invoice, the tax determination values (amount, Ship-to, Ship-from, etc.) are sent to the add-on and the expected tax values are returned and compared against the vendor invoice. When there is a mismatch, an invoice exception is generated and sent to an error handler via workflow for resolution in Ariba Invoice Management. Once the correct tax is applied, the invoice is sent to your back-end ERP for posting and payment.
Again, there should be no tax validation configured in the back-end ERP for Ariba Invoices as you’ve just dealt with tax management in the Ariba system.
Option 3 – Taxes are Simply Passed through Ariba and Managed in your Back-end ERP
In this scenario, tax values are simply passed through Ariba Invoice Management without validation and sent to the back-end for tax management (ie. SAP ECC / S4).
If you are using the Ariba Invoice Management module, this means that you cannot manage all invoice exceptions in Invoice Management directly as tax exceptions would be managed in the back-end. From an end user perspective, the disadvantage here is that two different systems are used to manage invoice exceptions.
However, if Ariba Invoice Management is not used, this means all invoice data is sent directly from Ariba Network to the back-end (ie SAP ECC / S4) and all invoice data & exceptions are managed in the back-end.
For SAP ECC / S4 customers, it is important to note that both ECC and S4 are weak when it comes to invoice exception and workflow management. Usually, an add-on such as Kofax or OpenText Vendor Invoice Management (VIM) is added to the architecture to manage invoice exception management and workflows. These add-ons also deal with tax exceptions, so you can manage all exceptions in a single interface. These add-ons usually consist of transports installed into your SAP system that add functionality to the code base (new tables, function modules, etc).
What About Using SAP Ariba Invoice Management for the “Direct Purchasing” Use Case?
t is important to note that if you are using the Ariba Invoice Management module for direct invoice exception management (i.e. with Commerce Automation or Supply Chain Collaboration licenses), header or line item taxes are not fed from your back-end to the Ariba Network and then to Ariba Buying & Invoicing when you output your PO from the back-end (ie. SAP ECC / S4). This means that without enhancements, Option 1.1 listed above is not supported by Ariba Invoice Management. For direct invoices, you can therefore only validate the tax at the invoice level (Option 1.2 & 2) or send to the back-end for validation (Option 3).
Other Considerations
As you evaluate the above tax management options and the architecture needed to implement them, don’t underestimate the implications and complexity of post-implementation support in your decision.
———————————
What have been your experiences supporting tax scenarios in Ariba solutions? What has worked well? What challenges have you faced? Let me know in the comments.
If you liked this post, why not Subscribe
Last Updated on January 8, 2021 by Joël Collin-Demers
