Skip links

Your tax engine is not a rate calculator. It’s the closest thing your ERP has to a consistent transaction control.

Author: Published on: Published in: Blog

Most organisations still describe an indirect tax solution as a way to automate tax rates.

That description significantly understates what a properly designed tax engine can do.

Yes, it must calculate tax. However, before it can calculate anything correctly, it has to answer a far more important set of questions:

  • Who are the parties to the transaction?
  • What is being bought or sold?
  • Where is it moving from and to?
  • Which legal entity and registrations are involved?
  • When does the transaction take place?
  • What is the nature and business purpose of the transaction?

Those questions arise throughout order to cash and procure to pay. They can also arise in expenses, projects, intercompany processing, journals and other financial flows.

This is why I believe the tax engine is one of the most underused control mechanisms in an ERP.

The closest thing to a common decision layer

An ERP is made up of different applications and processes. Order management controls an order. Procurement controls a requisition or purchase order. Accounts receivable produces the customer invoice. Accounts payable records the supplier invoice. Projects, expenses, inventory and intercompany processing each have their own responsibilities.

Many controls are specific to one of those processes. Tax determination is different.

Tax has to evaluate transactions on both the revenue and spend sides of the organisation. It must repeatedly consider many of the same fundamental data points, including the parties, product or service, legal entity, geography, registration, date and transaction type.

That makes tax determination one of the few enterprise rule frameworks capable of applying a governed and consistent policy at multiple transaction points across both order to cash and procure to pay.

I use the words “one of the few” deliberately. It would not be technically accurate to claim that every ERP product contains one physical tax engine that is invoked identically by every module. ERP architectures differ. Some use native tax services, some use tax codes and condition techniques, some call an external engine, and some recalculate tax as a document moves to its next stage.

The defensible point is this: tax determination can provide a common decision and control layer across transaction processes, provided it is designed, configured and integrated to do so. That is an opportunity created by the ERP architecture, not an automatic outcome of installing the software.

Oracle provides perhaps the clearest example

Oracle E-Business Tax is explicit about its cross-process role. Oracle states that E-Business Tax calculates tax on order-to-cash transactions from Projects and Receivables, and on procure-to-pay transactions from Purchasing and Payables. It can also handle transactions from source applications that feed Payables or Receivables. Oracle E-Business Tax User Guide

Oracle Fusion Cloud follows the same broad principle. In procurement, Oracle Fusion Purchasing integrates with Oracle Fusion Tax so that tax is calculated on purchase requisitions, recalculated on purchase orders and recalculated again when an invoice is matched in Payables. Oracle can then identify tax differences caused by changes in price, tax rate or currency conversion. Oracle Fusion Tax: Payables transaction examples

On the sales side, Oracle documents tax on the sales order and the subsequent Receivables invoice within the order-to-cash flow. Oracle Fusion Order Management: sales order and invoice tax

More importantly, Oracle Fusion Tax does not simply select a percentage. Its documented determination process evaluates transaction header and line information to derive the applicable regime, jurisdiction, applicability, registration, status, rate, taxable basis, calculation and, on purchasing transactions, recovery. Oracle Fusion Cloud Financials: Using Tax

That is not a rate lookup. It is a structured decision about the tax treatment of the transaction.

The same principle appears across other major ERPs

The terminology and technical design vary, so these products should not be described as though they all work like Oracle. Nevertheless, the cross-transaction role of tax is visible across the market.

SAP

SAP requires particular care because its tax architecture varies by product, module, country and implementation. SAP documents tax determination within Sales and Distribution, while its financial documentation covers tax on sales and purchases. In many S/4HANA designs, condition techniques, pricing procedures, tax codes and country-specific functions work together. I would therefore not describe every SAP deployment as using one identical physical engine across all modules. SAP S/4HANA: Tax Determination SAP S/4HANA: Tax on Sales/Purchases

SAP Business One provides a particularly clear illustration of the underlying principle. SAP documents tax codes used in both sales and purchasing documents, as well as automatic tax in journal entries. Its tax code determination rules can be scoped to sales, purchasing or both. SAP Business One: Managing Sales and Purchasing Tax

The implementation mechanics differ, but the opportunity is the same: govern tax logic centrally enough that sales and purchasing do not invent separate interpretations of the same tax policy.

Workday

Workday transaction tax rules automatically populate the appropriate tax code and tax applicability on taxable documents. Workday uses sales item groups for revenue rules and purchase or expense item groups for spend rules. It also supports tax rules based on countries, items and worktags, with worktag-based defaulting available at line level on supplier invoices, purchase orders and ad hoc payments. Workday: Configure Transaction Tax Rules

Again, tax becomes a shared set of rules applied to both revenue and spend data, rather than a calculation performed only after the transaction is complete.

Microsoft Dynamics 365

Microsoft’s Tax Calculation data model spans a wide range of transaction types, including sales orders, purchase orders, transfer orders, purchase requisitions, requests for quotation, sales quotations, free-text invoices and journals. The model exposes common header and line attributes such as business process, customer or vendor, registration data, locations, item, quantity and tax direction. Microsoft Dynamics 365: Tax Calculation data model

Microsoft also allows rules to determine tax groups, item tax groups, customer registrations, vendor registrations and list codes, and it provides configurable error handling for calculation results. Microsoft Dynamics 365: Get started with Tax Calculation

This is a strong example of how tax determination can consume a consistent data model across different business processes.

NetSuite

NetSuite SuiteTax determines a nexus for each sales or purchase transaction and triggers the tax engine assigned to that nexus. The resulting tax details can include the tax type, tax code, tax basis, rate, amount and details returned by the engine. NetSuite SuiteTax: Nexus determination NetSuite SuiteTax: Tax details on transactions

The significance is not simply that NetSuite calculates both sales and purchase tax. The same nexus and tax-engine framework is used to decide which calculation logic applies to each side.

Infor

Infor also demonstrates the pattern, although its products have different tax architectures. Infor LN lists tax calculation across sales invoices, purchase invoices, service invoices, project invoices, interest invoices, advance payments, settled discounts and journal vouchers. Infor LN: Tax calculation

Infor Distribution SX.e uses the company tax method and selected tax interface to determine the logic used when calculating taxes on both sales orders and vendor invoices. Infor Distribution SX.e: Tax method and interface

Once again, the exact product design differs, but tax is positioned across transaction types rather than being isolated within one finance process.

What should the tax engine be checking?

A properly configured tax solution should do more than return 20%, 5%, zero or exempt.

It can use the data already present on the transaction to establish the treatment and preserve information explaining that outcome. Depending on the capabilities of the ERP or connected engine, that may include:

  • the applicable tax regime and jurisdiction;
  • the relevant company, customer or supplier registration;
  • the product or service classification;
  • the place of supply;
  • whether the transaction is taxable, zero-rated, exempt, outside scope, self-assessed or subject to reverse charge;
  • the taxable basis and calculation method;
  • the recoverable and non-recoverable amounts on purchases;
  • the tax code, tax status and reporting classification; and
  • the reason why the treatment was selected.

This allows the tax engine to do much of the heavy lifting without asking the user to become a tax specialist.

Where the platform supports warnings or errors, the same rules can also expose missing or inconsistent determining data. The objective is not to make tax responsible for every element of financial-data quality. It is to make tax a powerful control over the transaction data that it consumes, tests and classifies.

Three practical examples

Consider a transaction for which the tax engine does not receive all the information needed to determine the correct treatment. The engine should be configured to identify the missing or inconsistent input and retain sufficient detail about the determining facts, rules and result for the exception to be found quickly through reporting, analytics or AI. The transaction does not necessarily have to fail. The important point is that the gap becomes visible and traceable.

Where a missing item must prevent completion, the tax determination can return a designated error tax code or status. This gives the downstream workflow a simple value already held on the transaction to identify, rather than requiring customised validation logic for every jurisdiction and scenario.

For example, suppose a VAT registration number is required only for particular combinations of ship-from location, ship-to location, transaction type and jurisdiction. Building that logic into the sales or invoicing workflow would require multiple validations and exceptions. The tax engine already evaluates those determining facts. Its rules can return the designated error tax code whenever the relevant VAT registration number is absent.

Multiple tax rules can therefore produce the same controlled outcome. The application workflow needs only one test: if the tax code equals the designated error value, place the transaction on hold. The country-specific and tax-specific logic remains governed in the tax engine, rather than being duplicated throughout ERP workflows.

The designated error tax code must be configured so that it cannot be treated as reportable tax or posted as a valid accounting outcome. It is an exception indicator that must be resolved before the transaction can proceed.

If tax determination fails or produces an apparently incorrect result, that result can also expose a weakness in the upstream information. The tax team can examine the captured inputs and decision path to identify whether the source data, process or rule requires correction.

Prevention is better than cure, but tax cannot control every upstream process from which determining information originates. Where prevention is possible, the tax engine can standardise the exception outcome. Where it is not, the next best thing is early diagnosis. The information captured through tax determination can then provide the evidence needed for reporting, analytics and AI to identify potential issues quickly and trace them back to their source.

Consider a transaction where the tax engine calculates tax using the ship-to address recorded in the ERP, but the goods are subsequently redirected and the shipping label is changed manually. The recorded transaction data points to one tax treatment, while the actual movement of the goods points to another.

If a user overrides the calculated tax, the system should, where it has the capability, retain the original automated determination, the manually selected replacement tax code and resulting tax, and the fact that an override occurred. Oracle ERP, for example, provides this capability. Where the platform supports it, the audit trail should also link the change to the user who made it and record when it was made, the reason for the change and any supporting evidence.

This gives the tax team a controlled population of overrides to analyse. It can distinguish a documented workaround from an error, investigate the upstream data, process or tax rule that caused the discrepancy, and preserve the evidence needed to explain the transaction during a future audit.

The analysis can also identify patterns associated with particular users, teams, transaction types or processes. Repeated overrides by an individual or team may indicate that additional training is required. Alternatively, they may reveal that users are compensating for incorrect master data, an inadequate upstream process or a recurring weakness in the tax logic.

In some organisations, a user may be tasked with periodically reviewing errors and correcting them manually. Because the exceptions are continually fixed, the final transactions may appear error-free, while the wider business has no visibility of the number of corrections being made or the time and cost involved. A relatively small correction to the tax logic could remove that repetitive work and release valuable resources for more productive activity.

The value therefore lies not only in explaining an individual override. Tax determination and override data can be used to identify the problems occurring, understand how they are currently being corrected, and decide whether the appropriate response is improved tax logic, better source data, a process change or additional user training.

This becomes increasingly important with e-invoicing, SAF-T and near-real-time digital reporting. A tax authority may receive the same structured transaction data and identify an inconsistency between the recorded destination and the overridden tax treatment. A governed determination and override process makes that inconsistency visible internally before it becomes an external compliance issue.

Simply allowing a user to select or replace a tax code provides no equivalent control. The objective is not necessarily to prohibit every override, but to ensure that overrides are visible, explainable and used to identify weaknesses in the underlying data and processes.

“In an AI-enabled world, organisations can no longer afford incorrect or inconsistent transaction data. The value of AI will depend on the quality and governance of the information it is given.”

Consider tax determination on a purchase order. Where VAT is fully recoverable, calculating it may provide useful information, but it does not normally increase the ultimate expense of the purchase. The position is different where VAT is non-recoverable or only partially recoverable. The non-recoverable portion becomes a real cost to the business and should therefore be visible at the purchase-order and approval stage.

This can provide a valuable control for the buyer and approver. If the system is configured to show a tax line on the purchase order only where some or all of the tax is non-recoverable and therefore represents an expense to the business, its appearance becomes an obvious exception requiring attention. The buyer can immediately see that the expected cost is higher than the underlying purchase value and that the additional expense may affect the available budget or approval requirements.

For example, a buyer may believe that a purchase will cost €10,000. If VAT at 20 per cent is fully non-recoverable, the actual cost becomes €12,000. That additional €2,000 may cause the purchase to exceed the buyer’s budget or move it above an approval threshold. Identifying the cost before commitment allows the buyer or approver to reconsider the purchase, adjust the budget or obtain the necessary approval. Without that determination, the additional expense may become visible only when the supplier invoice arrives.

This is tax logic acting as a wider financial control. Correctly determining recoverability does more than produce the appropriate tax treatment. It informs procurement, budgeting and approval decisions using the true expected cost of the transaction.

Any determination at the purchase-order stage can use only the information available at that time. If the organisation is buying a new product or service, the item may initially have an incomplete or provisional tax classification. The supplier may have better information about what is being supplied and apply a different classification when preparing its invoice.

When that invoice enters Payables, the tax engine should reassess the transaction. If the invoice contains no new or changed information, the engine may produce the same result as it did on the purchase order. If additional information is available, such as a more accurate product or service classification or an UNSPSC code linked to the item, that information should be incorporated into a new determination.

The correct invoice treatment may therefore differ from the purchase-order treatment. That difference is not necessarily an inconsistency or error. It may be the correct consequence of applying the same governed tax rules to more complete or accurate information.

The same principle applies to sales. A sales order may initially be determined using a particular ship-from warehouse. By the time the goods are picked, that warehouse may no longer have sufficient stock and fulfilment may be transferred to another location. The replacement warehouse could be in a different jurisdiction or country, or it could have a different legal or customs status, such as being bonded rather than non-bonded.

When the goods are picked, shipped and ultimately invoiced, the tax engine must use the actual fulfilment information. If the ship-from location has changed, the appropriate tax treatment may also have changed. The original result should not simply flow from the sales order through to the invoice without reassessment.

This is another reason why the tax engine must do the heavy lifting throughout the transaction lifecycle. A manually selected or customer-defaulted tax code carried forward from the original order cannot respond reliably when the classification, location or other determining facts change.

A consistent tax engine does not necessarily produce the same answer at every stage. It consistently applies the same governed decision framework to the facts that are relevant and available at that point.

The wider value is financial-data quality

Every tax decision is also a data-quality test.

To determine tax correctly, the system needs reliable legal-entity data, customer and supplier information, registrations, product and service classifications, locations, dates and transaction attributes. If those inputs are incomplete or inconsistent, the tax result can expose the weakness, provided that the determination rules and exception reporting have been designed to do so.

One practical example is the classification of every transaction line as either goods or services. In Payables, this classification should be captured explicitly. In Receivables, it should normally flow automatically from controlled product, item or transaction setup. The distinction is essential for tax determination because goods and services can follow fundamentally different indirect tax rules.

It also creates a valuable data-quality control for the wider business. A transaction description may state that training services are being supplied, while the selected item or transaction line is classified as goods. That discrepancy may indicate that the user has selected the wrong item, used an inappropriate transaction type or encountered an underlying master-data problem.

The tax engine can use the controlled classification when determining the tax treatment. The resulting data can then be combined with descriptions, customer or supplier information and other transaction attributes in reporting, analytics or AI to identify inconsistencies between what the transaction says is being supplied and how it has been classified.

ERP applications are increasingly incorporating AI tools that operate within particular modules and understand the structured fields and business context available to them. If required information is missing, incomplete or incorrectly classified, the quality of the resulting analysis will also be affected.

A well-designed indirect tax solution creates a governed record of the information used to determine tax, the rules applied and the resulting treatment. That information can be supplied to analytics and AI to identify patterns, exceptions and opportunities for improvement. The findings can then be used to correct source data, improve user processes or refine the tax logic.

This creates a continuous improvement cycle: better tax determination produces better-controlled data; better analysis identifies weaknesses; and those findings can be fed back into the processes and tax configuration that created the data.

Poor data does not become trustworthy because it is passed to an AI model. The value of AI still depends on the quality, consistency and meaning of the underlying transactions.

Is tax the perfect partner for AI?

Tax determination and AI have complementary strengths. In many respects, tax may be one of the strongest partners available to AI within an ERP.

A properly designed tax engine applies governed rules to structured transaction data. It consumes information about legal entities, customers, suppliers, registrations, products, services, locations, dates and transaction types. It then records the treatment produced, the information used and, where the platform supports it, any exceptions or manual overrides.

This provides AI with something extremely valuable: structured financial data that has passed through a controlled decision framework shaped not only by the organisation’s tax solution, but also by the requirements of the tax authorities and regimes to which it must report.

An indirect tax solution is designed to determine, document and report the appropriate treatment in each relevant jurisdiction. These requirements have developed over many years and collectively define much of the transaction data, classification and evidence that an organisation must retain to demonstrate compliance. If the business can consistently meet those requirements across multiple tax regimes, it is likely to have established a strong standard of financial transaction data on which AI can operate.

The requirements are not identical in every jurisdiction, and tax compliance alone does not guarantee perfect data quality. However, they provide a valuable externally defined baseline for registrations, classifications, locations, transaction types, dates, values and other determining information.

This is particularly relevant as ERP providers incorporate AI directly into their applications. These tools operate using the structured fields, relationships and business context available within each module. If important information is absent, inconsistent or incorrectly classified, the resulting analysis may also be incomplete or misleading.

AI can analyse tax determination data at a scale that would be difficult for a tax team to achieve manually. It can identify recurring exceptions, concentrations of overrides, inconsistent classifications and patterns associated with particular users, suppliers, customers, products, locations or processes.

For example, AI could identify that one team regularly overrides the same tax result, that descriptions referring to services are repeatedly associated with items classified as goods, or that transactions involving a particular jurisdiction frequently fail because registration information is missing. These findings may reveal a training requirement, incorrect master data, an upstream process weakness or a relatively small defect in the tax logic.

This creates a continuous improvement cycle:

  1. The tax engine applies governed rules and captures the determining information and result.
  2. Reporting, analytics and AI identify patterns, exceptions and inconsistencies.
  3. Tax and business teams investigate the underlying causes.
  4. Source data, user training, business processes or tax rules are improved.
  5. Subsequent transactions produce better data and more reliable outcomes.

The findings generated by AI can help improve the tax solution, but they should not automatically change tax rules or transaction treatments without appropriate review, testing and governance. AI should enhance the control framework, not replace it.

If AI is expected to provide insight into financial transactions, the underlying data must be complete, consistent and compliant. Applying AI to weak or non-compliant transaction data does not resolve the weakness. It risks producing analysis that is equally unreliable.

Tax is therefore a strong partner for AI because it can supply governed context, controlled classifications and explainable decision data. AI, in return, can help tax and finance teams find patterns and weaknesses that conventional transaction-by-transaction review may never reveal.

“Tax can give AI governed, compliance-focused transaction data. AI can give tax the ability to learn from patterns across every transaction.”

This is why tax must be involved early

If the tax team is brought into an ERP programme after the entity model, master data, process design, interfaces and reporting architecture have already been agreed, the project may have removed or obscured information that tax determination needs.

Correcting that later can require redesign, additional development, repeated testing and manual workarounds.

Tax specialists who understand both the legislation and the ERP can act as translators between the tax team, the business, the implementation partner and the technology architects. Their role is not simply to provide a list of rates. It is to ensure that legally required outcomes can be delivered through the chosen system and that the transaction carries the information needed to explain and report those outcomes.

The question ERP programmes should be asking

Do not ask only:

“How will the system calculate the tax rate?”

Ask:

“How can tax determination apply a consistent set of checks across every relevant transaction process, and what controlled information should it add to the transaction?”

That is a much bigger question, but it leads to a much better ERP design.

The tax engine should not be treated as a tax-department utility hidden at the end of a transaction. Properly designed, it becomes one of the most consistent and valuable transaction-control layers available across the enterprise.

author

Andrew is the founder of Innovate Tax and chairs the Oracle Tax Management SIG. With 25 years of implementation experience, he is the go-to indirect tax technology expert. Internationally recognised as the best in his field, Andrew presents globally on all forms of indirect tax.

You may also like