“We’re on EBS” tells me almost nothing about your tax maintenance burden. “We’re on 11.5.10,” “we’re on 12.1.3,” and “we’re on 12.2.12” describe three different tax architectures, three different support realities, and three different answers to the question what does it cost us to stay compliant without Oracle? Having supported all three — 10.7 through 12.2.4 across the Rimini Street years — here is the release-by-release picture.
The short version
| 11i (11.5.x) | 12.1.x | 12.2.x | |
|---|---|---|---|
| Tax engine | None — per-module tax codes | E-Business Tax (ZX), centralized | E-Business Tax (ZX), centralized |
| Where rates live | AP_TAX_CODES_ALL (AP/PO), AR_VAT_TAX_ALL (AR), tax groups, location-based tax in AR | ZX_RATES_B under regime-to-rate | ZX_RATES_B under regime-to-rate |
| Support status | Sustaining since 2013 | Sustaining since Jan 1, 2022 | Premier through at least Dec 2037 |
| 1099 year-end patches | No | No — frozen at last delivered format | Yes, annually |
| Bulk setup tooling | Module by module | HTML Tax Managers UI | UI plus Tax Implementation Workbook (Excel, nine worksheets) |
| A rate change means | Touching each module’s codes separately | One change in ZX, all modules inherit | One change in ZX, all modules inherit |
| Biggest tax risk | Fragmented setup drifts out of sync | Format freeze + no engine fixes | Complacency — support ends eventually here too |
11i: tax before the tax engine
There is no E-Business Tax in 11i, and no ZX schema. Each module taxes for itself:
- Payables and Purchasing use tax codes in
AP_TAX_CODES_ALL, optionally bundled into tax groups so one line can carry several taxes, with offset tax codes handling self-assessed use tax. - Receivables uses its own codes in
AR_VAT_TAX_ALL, plus location-based tax for US sales tax, driven by AR’s own location and rate structures. - There are no regimes, statuses, jurisdictions, or shared rules. “Standard rate went up” means updating AP’s codes and AR’s codes and checking every tax group that references them — and the modules will not notice if you miss one.
For the shops still running it (they exist; I’ve supported them), the compliance work is the same quarterly calendar as everyone else but executed two or three times over, once per module, with a reconciliation query at the end to prove AP and AR agree about what the standard rate is. The one mercy: the 11i structures are simple, flat tables, and after a decade-plus of Sustaining Support these shops have no illusions about anyone coming to help.
One 11i-specific trap worth naming: if you are planning an upgrade, know that the R12 upgrade migrates your tax codes into ZX as tax classification codes (lookups ZX_INPUT_CLASSIFICATIONS for AP/PO codes, ZX_OUTPUT_CLASSIFICATIONS for AR/Projects codes) using a direct-rate-determination model built to reproduce your 11i results — it does not magically produce a clean regime-to-rate design. Reverse-charge VAT codes come across tagged with the REVERSE_CHARGE_VAT reporting code. And per MOS note 1485382.1, some 11i codes arrive with no corresponding ZX_RATES_B row at all — an upgraded instance deserves a reconciliation between its old code list and its new rate table before anyone trusts it.
12.1: the full engine, frozen
12.1 has the complete modern architecture — the regime-to-rate hierarchy, centralized rules, TCA geography, one engine serving every module (the previous article in this series maps the tables). Functionally it is nearly identical to 12.2’s engine. What distinguishes 12.1 is purely the support position: Sustaining since January 1, 2022, which for tax means:
- No 1099 year-end patches. Your form layouts and e-file formats froze at tax year 2021. The IRS has changed both every year since — box renumbering, the 1099-NEC’s continued evolution, the FIRE-to-IRIS filing transition. The workable paths are exporting AP’s 1099 data to a filing service (the data in Payables is fine — supplier balances, income tax types, withholding all accumulate exactly as before; only the output formats are stale) or maintaining custom report templates annually.
- No localization content. EMEA VAT register formats, ECE reporting, country statutory outputs (the JG/JE layer) stopped evolving. If a member state changes a declaration format, the delivered report will not follow it.
- No engine fixes. A ZX defect — recovery-rate misapplication, a determining-factor edge case, an extract bug — is now a diagnose-and-custom-fix exercise. This is rarer than people fear on a mature 12.1.3 (the engine has been stable for years) but when it happens, it is exactly the write-the-fix-yourself work this practice exists for.
- Rate content: unchanged. As covered in the first article of this series, Oracle never shipped transaction tax rates. Partner feeds (Vertex, Avalara, ONESOURCE) keep flowing; manual maintenance stays manual.
12.2: the same engine, still on the patch train
12.2 runs the same ZX data model — a 12.1 tax person is immediately at home — with two real differences.
First, it is supported until at least December 2037. The annual 1099 patches still arrive (tax year 2025’s changes shipped as a year-end patch requiring its prerequisite bug fix, same as every year). Localization content still flows. Engine bugs still get patches. If you are on 12.2 and staying, your tax maintenance burden is the content calendar only — rates and geography — which was always yours.
Second, the tooling is better: the Tax Implementation Workbook, an Excel template with nine setup worksheets, handles bulk configuration loads that 12.1 does through the UI one screen at a time. For a quarterly rate cycle of a few dozen changes the difference is convenience; for an implementation or a mass jurisdiction load it is substantial.
One 12.2-specific operational note: online patching (adop) means patches — including tax seed data — flow through editioned tables and a cutover. That is invisible to the tax administrator day-to-day, but it is why “just apply the year-end patch Friday night” involves your DBA in a way 12.1 shops don’t remember.
What each module actually asks of the engine
Release differences matter because of what sits on top. In R12, every subledger calls the same ZX services, but each brings its own wrinkles — and its own things that are not EBTax at all:
| Module | What it sends the engine | Module-specific wrinkles |
|---|---|---|
| Payables | Invoice header/line attributes → input tax | Self-assessed use tax via offset configuration; recovery rates where input tax is partially recoverable (Canadian GST/HST shops live here); tax variances against the PO |
| Receivables | Transaction lines → output tax | Exemption certificates (ZX_EXEMPTIONS) with their own effective dates; credit memos must recalculate at the original invoice’s rate — the reason in-place rate edits corrupt history |
| Purchasing / iProcurement | Requisition and PO lines | Tax is estimated at requisition/PO time — determining factors snapshot into ZX_LINES_DET_FACTORS, amounts into the PO distributions — then recalculated at invoice; verification queries differ from AP’s (MOS 2251671.1 covers table-level PO tax checking) |
| iExpenses | Expense report lines → AP | Inherits AP’s configuration; the trap is expense templates hardcoding old tax classification codes |
| Projects | Expenditure/invoice flows | Output classifications on the AR side of project billing |
| Payables (again): withholding | — | Withholding tax (AWT) is not E-Business Tax in any EBS release. It lives in Payables: special calendar, withholding codes and groups, invoice-time or payment-time withholding, feeding 1099/1042 reporting. A “tax review” that only covers ZX has not looked at withholding; a withholding threshold change is an AP setup change, not a ZX one. (Oracle’s Cloud ERP moved withholding into the central engine — EBS never did, on any release.) |
Reading your own position
Three questions locate you on this map. Which release? — that decides whether formats and fixes still arrive (12.2), stopped in 2022 (12.1), or stopped long ago (11i). Who feeds your rates? — a partner integration or a named human with a quarterly calendar; “nobody, they haven’t changed in a while” is the answer that should worry you. Who fixes the engine? — for 12.2, Oracle; for anyone else, either nobody or somebody who has done it professionally.
The pattern across all three releases: the tax data model keeps working indefinitely — 11i shops have proven that for over a decade. What decays is everything at the edges: output formats, statutory reports, geography currency, and the safety net under the engine. Those edges are maintainable. They are simply no longer maintained for you.
Not sure which of your edges has already decayed? Describe your release and your tax setup — I’ll tell you what’s frozen, what’s fine, and what a remediation actually costs.