How tax strategy and planning is set up in finance and ERP systems

Tax strategy and planning usually sits outside the ERP itself. The ERP holds the tax master data and produces the transactional figures, while strategy, scenario modelling and the consolidated plan live in spreadsheets and specialist tools that draw from it. How well that link holds decides most outcomes.

Where the pieces live

The general ledger and subledgers carry the raw material. Every invoice, payroll run and intercompany charge lands there with a tax code, a legal entity and usually a jurisdiction attached. That is the foundation the tax team plans on.

The planning itself tends to happen elsewhere. Some groups use a tax provision or tax planning application that pulls trial balances by entity. Many still rely on workbooks maintained by a small group of specialists, fed by exports from the ERP and from the corporate budgeting tool. Larger organisations often run a mix, with the formal tool for the year end provision and workbooks for anything forward looking.

Advisers frequently hold part of the picture too. Transfer pricing studies, structuring memos and treaty analysis may sit in documents that never touch a system at all.

Strategy by jurisdiction

Foreign, national, state and local positions are normally developed separately before anyone tries to join them up. Each layer has its own owners and its own rules, and often its own outside adviser.

In system terms, this work depends on the legal entity structure being right. If the ERP models entities, branches and permanent establishments accurately, the tax team can see income and activity where it actually arises. If the structure has drifted, for example because a branch was booked inside its parent for convenience, the strategy work starts with manual reallocation.

State and local planning leans heavily on apportionment data such as payroll by location, property and sales by destination. These figures are rarely captured cleanly for tax purposes. Someone usually builds them from HR, fixed asset and billing reports each cycle.

Bringing the plan together

Consolidating the total tax plan means combining the jurisdictional views with the group budget or forecast. The effective tax rate, cash tax and deferred tax forecasts all come out of this step.

The common pattern is a hand off. Financial planning produces pre-tax forecasts by entity. Tax applies rates, adjustments, credits and planned actions, then sends a tax line back into the plan. Optimisation happens in the gap between those two moments, where the team tests scenarios like moving a function, changing a financing arrangement or accelerating a deduction.

Timing is the usual friction. The budget calendar is set by the planning team, and tax often receives numbers late and with less detail than it needs. Where the planning tool lets tax own its own lines and versions, the cycle runs more smoothly. Where it does not, tax keeps a shadow model that slowly diverges from the official one.

Tax master data in the ERP

This is the part that genuinely lives in the transactional system. It covers tax codes and their rates, tax registrations by entity, jurisdiction mappings, customer and supplier tax attributes, exemption certificates, and the account mapping that tells the provision which ledger lines are taxable, deductible or permanent differences.

Ownership is often split. Indirect tax codes may sit with an accounts payable or billing team. Account mapping for the provision may be maintained by tax. Vendor tax identifiers may be entered by procurement. Each group changes its own piece without much visibility of the others.

Good setups put controls on who can create or change tax codes, keep an effective dated history so past periods remain reproducible, and review mappings whenever new accounts are opened. Many organisations add a third party tax engine for indirect taxes, which then becomes a second home for rates and rules that must stay aligned with the ERP.

Questions to ask the people who run it

The documented process and the lived one often differ. These questions tend to surface the gap:

• Which numbers do you actually start from, and where do you get them?
• Is there a workbook that the process cannot run without? Who maintains it?
• When the forecast changes after you have applied tax, how do you find out?
• Who can create a new tax code or change an account mapping, and who approves it?
• How do you rebuild apportionment data each cycle?
• Which entity or branch is set up in the ERP differently from how it is treated for tax?
• What do advisers provide that is not stored anywhere internally?
• When a planned action is agreed, how does it reach the forecast and the books?
• What do you check by hand because you do not trust the system output?

Where changes tend to go wrong

Most redesigns focus on the planning tool and underestimate the master data. A new tax planning application inherits every mapping error from the ledger, and those errors become harder to spot once they are hidden behind a cleaner interface.

Another frequent problem is losing the informal steps. A specialist who quietly adjusts an export before loading it is performing a control. If the new design automates the load, that adjustment disappears unless someone has written it down.

Finally, strategy decisions need a route into operations. A plan to change an intercompany charge or register in a new location only works if billing, procurement and accounting update their setup at the right moment. Tracing that path end to end, from the decision through to the tax code on the next invoice, is usually where the real redesign effort belongs.

APQC's Process Classification Framework® (PCF) is an open standard developed by APQC, a nonprofit that promotes benchmarking and best practices worldwide. To download the full PCF or to view definitions and measures, please visit www.apqc.org/pcf.