UK: 
USA:
When an organisation is preparing to move from Oracle E-Business Suite R12 to Oracle Fusion Cloud ERPEnterprise resource planning (ERP) is a type of software that organisations use to manage main business processes., it is natural to focus on the wider finance transformation programme: new processes, new reporting structures, new integrations, new controls and new ways of working. However, indirect tax should not be treated as something to be designed from scratch at the end of the programme.
Tax is different from many other ERP design areas. A client may redesign its chart of accounts, approval workflows, procurement model, reporting structures or operating processes, but the underlying tax rules are not created by the client. They are driven by legislation, tax authority requirements and the facts of the transaction. Moving from Oracle R12 to Oracle Cloud does not change whether a transaction is taxable, exempt, reverse chargeWhen the Reverse Charge (mechanism) is in effect, the recipient of goods or services assumes responsibility for reporting both the purchase and the supplier’s sale in their VAT return., recoverable, non-recoverable, zero-rated or subject to a specific local rule. What changes is the system environment in which those rules must be captured, automated, tested and controlled.
For that reason, there is a strong case for implementing Innovate Tax’s inFlyte™ Oracle tax solution into Oracle R12 before the Cloud migration. By doing so, the business can establish, test and validate the tax logic while still operating in the current environment. The Cloud migration can then treat tax as a known, structured and controlled workstream rather than as a late-stage design issue.
Separating tax design from Cloud migration
Implementing the tax framework before the upgrade allows the business to separate two very different challenges.
The first is defining how tax should work. This includes identifying the tax scenarios, confirming the data required to determine the correct tax treatment, reviewing customer and supplier master data, understanding purchase-to-pay and order-to-cash flows, mapping country-specific requirements, identifying gaps in source data, and agreeing the reporting and compliance outputs required by the tax team.
The second is migrating to Oracle Cloud.
If these two activities are carried out at the same time, the tax team, finance team, IT team and implementation partner are forced to resolve tax design, data quality, process gaps, system migration and user acceptance testing simultaneously. That increases programme pressure and can make tax a bottleneck.
By implementing the tax framework in Oracle R12 first, the client can move into the Cloud programme with a clearer view of the tax scenarios that must be supported, the Oracle attributes and transaction data required for tax determination, the customer, supplier, item, legal entity and transaction data that needs to be accurate, the reporting and compliance requirements that must be protected, the test scripts needed to prove the solution, and the known gaps, risks and decisions that must be carried into the Cloud design.
A controlled lift-and-shift workstream
For many areas of an ERP implementation, a move to Cloud is an opportunity to redesign business processes. Tax should be approached differently.
The client may change the system, but the tax authority rules remain outside the client’s control. Once the tax framework has already been designed, optimised, tested and understood in Oracle R12, the Cloud programme can focus on lifting, migrating and validating that framework rather than redesigning it from first principles.
This is particularly relevant because Oracle R12 eBTax and Oracle Cloud Tax share an almost identical underlying tax framework and approach to tax determination. While there are some small differences and functional enhancements in Oracle Cloud, the core tax functionality, tax logic, tax rules, tax data requirements and determination concepts remain the same.
For that reason, this is not simply a theoretical lift-and-shift argument. For tax, the established Oracle R12 content can genuinely be lifted, migrated and validated in Oracle Cloud because the underlying functionality is the same and there is no need to redesign the tax content simply because the platform is changing.
Why inFlyte™ supports this approach
Innovate Tax’s inFlyte™ Oracle Plugin is designed specifically for Oracle ERP. inFlyte™ is loaded directly into Oracle using our RapidInstall™ methodology and establishes a prebuilt, structured indirect tax framework using Oracle tax functionality. Rather than operating as an external third-party tax engine, inFlyte™ works within Oracle, meaning the tax logic is configured in the Oracle environment and aligned to how the client already uses Oracle.
Because the framework can be implemented quickly, the client can begin testing tax within a matter of days rather than waiting for a long manual configuration build. This makes testing more accurate from the start because real tax rules, data requirements and determination logic are available early in the project, allowing issues to be identified and resolved before they become late-stage programme risks.
RapidInstall™ can deploy months of tax configuration work in a matter of hours, allowing a working tax framework to be established far earlier than would be possible through manual configuration. It can also extract only the tax-related configuration from one Oracle environment and load it into another, whether that is from Test to UAT, between Cloud environments, or even from an Oracle R12 production instance into Oracle Cloud.
Reducing programme risk
Tax configuration is complex and often depends on detailed country rules, transaction attributes, master data, legal entity structures, reporting needs and upstream integrations. In many ERP programmes, tax receives limited attention, with the focus often placed on replicating existing tax rates and basic tax code structures rather than designing a comprehensive, globally consistent tax framework.
Implementing the tax framework in Oracle R12 first allows the client to establish and validate the tax design before the Cloud programme reaches critical stages. It creates a proven tax solution that can be carried forward into the Cloud implementation, giving the implementation partner a defined and tested tax framework rather than requiring them to design one from scratch.
This removes a major area of uncertainty from the programme and reduces the risk that tax becomes a project bottleneck.
Improving testing, data quality and control
A working tax baseline gives the client something real to test. Instead of reviewing theoretical designs, the tax team can validate actual outcomes against agreed tax scenarios. The resulting test scripts and evidence can then be reused or adapted for Cloud testing.
A tax implementation is also often one of the best ways to expose master data and transaction data issues. Customer and supplier tax registration numbers, legal entity structures, ship-to and bill-to data, product or purchasing categories, intended use, tax dates, exemption indicators and other attributes may all affect the tax result.
By addressing these issues as part of the inFlyte™ implementation in Oracle R12, the client can undertake a structured master data validation and clean-up exercise well before the Cloud migration begins. The work performed during the tax implementation can also become part of the client’s tax control framework, helping the business move beyond “the system calculates tax” to “we can explain, evidence and control how the system calculates tax.”
Why this still helps if a tax engine is chosen later
Implementing inFlyte™ does not prevent the client from choosing a third-party tax engine in the future. In fact, it can make that future decision easier, safer and more cost-effective.
A third-party tax engine still needs the right data. It still needs to know the legal entities, transaction flows, ship-from and ship-to logic, customer and supplier tax status, product or service categories, exemption indicators, tax dates, reporting requirements and country-specific rules. If those foundations are not understood and structured, connecting a third-party tax engine will not solve the underlying problem.
In Innovate Tax’s experience, a significant proportion of any tax engine implementation, often around 80–85% of the effort, is not the calculation engine itself, but the work required to identify, capture, structure and pass the correct data to that engine.
That work does not disappear when the client changes tax engine. If the data requirements, transaction attributes, master data processes, tax logic and test scenarios have already been established through inFlyte™, a future third-party tax engine project can start from a much more advanced position.
A stronger foundation for Oracle Cloud
Innovate Tax brings together Oracle tax expertise, tax technology implementation experience, proprietary Oracle deployment tools and a structured project methodology. The value is not limited to configuration. It includes the full tax workstream: requirements, design, data, interfaces, testing, documentation, training, support and future readiness.
For a client moving from Oracle R12 to Oracle Cloud, this combination is particularly important. The tax workstream needs to be technically aligned to Oracle, but it also needs to be tax-led. Innovate Tax acts as the translator between the tax team and the Oracle solution, taking tax requirements and converting them into the tax logic, data structures, processes and controls needed to deliver a structured and standardised global tax solution.
In short, implementing inFlyte™ before a move to Oracle Cloud can reduce risk, avoid future change requests, save time and money, improve control and provide a stronger foundation for both the Cloud migration and any future tax technology decisions.
