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 product that is both purchased and sold. If its tax classification is governed properly, the purchasing and sales processes can use the same controlled classification instead of maintaining separate interpretations in different parts of the ERP.

Consider a VAT registration number. It should not matter whether the first relevant transaction appears in a sales order, a customer invoice, a purchase order or a supplier invoice. The tax design should use the appropriate registration and status consistently wherever the platform makes them available to determination.

Consider a supplier invoice matched to a purchase order. The correct tax at the order stage may not be the correct tax at the invoice stage because the date, price or other determining facts may have changed. Consistency does not mean blindly copying the first result. It means applying the same governed decision framework again, using the facts that are relevant at that point, and explaining any difference.

That distinction is essential. A consistent tax engine does not always produce the same answer. It produces the answer consistently.

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 will expose the weakness, assuming the rules have been designed to do so.

This gives organisations an opportunity to use tax as a control point for better-classified and more traceable financial data. That data then supports more reliable tax reporting, reconciliation, audit investigation and analytics. It also provides a stronger governed foundation for the future use of AI in finance.

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

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.

You may also like