When Oracle moved EBS 12.1 to Sustaining Support on January 1, 2022, the phrase in the support policy that mattered most to finance teams was five words long: no new tax and regulatory updates. Four years on, I still find that most 12.1 shops can’t say precisely what they stopped receiving — and, just as important, what they never received from Oracle in the first place.
That distinction is the whole game. Get it wrong in one direction and you panic about content you were never getting from Oracle anyway. Get it wrong in the other and you quietly file 1099s on a format the IRS retired two years ago.
What Oracle actually stopped shipping
Sustaining Support ended the flow of four specific kinds of regulatory content for 12.1:
| Content | What it was | Cadence when supported | Who is exposed |
|---|---|---|---|
| 1099-MISC/NEC year-end patches | Updated form layouts, box mappings, and electronic filing formats matching each year’s IRS specifications | Annual, typically October–December | Every US entity that pays reportable suppliers from Payables |
| Payroll tax tables and statutory updates | Federal/state/local withholding tables, limits, formats (HRMS/Payroll) | Multiple times per year | Shops running Oracle Payroll (most EBS Financials-only shops are not) |
| EMEA and country localization content | VAT reporting format changes, ECE registers, country-specific statutory reports (the JG/JE localizations) | As regulations changed | Entities with European or Latin American statutory reporting out of EBS |
| Regulatory bug fixes | Corrections when a delivered tax feature miscalculated or misreported | As needed | Everyone |
To calibrate what “annual 1099 patch” means in practice: for tax year 2025, the IRS moved excess golden parachute payments off Form 1099-MISC Box 14 onto 1099-NEC Box 3, renumbered the MISC nonqualified deferred compensation box from 14 to 15, and changed what can be filed through the FIRE system. Oracle delivered those changes to supported releases as a year-end patch. A 12.1 instance got nothing — its 1099 programs still print and file the last format Oracle shipped it, and the IRS does not accept old formats out of sympathy.
What Oracle never shipped: your transaction tax rates
Here is the part that surprises people. For E-Business Tax — the ZX engine that calculates sales tax, use tax, VAT, and GST on your AP, AR, and PO transactions — Oracle never delivered rate content at all. The engine ships empty. Every regime, tax, status, jurisdiction, and rate in your instance got there one of two ways:
- Someone in your organization typed it in (or loaded it), and has been maintaining it by hand ever since; or
- A tax partner feeds it — Vertex (Q Series or O Series), Avalara AvaTax, Thomson Reuters ONESOURCE, or Taxware, through the partner integrations Oracle documented for exactly this purpose.
This means the Sustaining Support cutoff did not stop your sales tax rates from updating — because Oracle was never updating them. If you have a partner integration, the partner keeps shipping content to roughly 13,000 US jurisdictions regardless of what Oracle thinks of your release, and the integration keeps working as long as the code on your side keeps running (which, on a frozen release, it does — nothing changes underneath it). If you maintain rates manually, your exposure is the same as it was in 2019; you just no longer have Oracle Support to call when the engine itself misbehaves.
The honest risk statement for an unsupported instance is therefore: manual-content shops carry rate-currency risk; every shop carries format risk (1099, statutory reports); and everyone carries engine risk (a ZX defect now needs a custom fix, not a patch).
Where tax rates actually come from
If you are maintaining content yourself, these are the authoritative sources, and all of them are free:
United States — sales and use tax.
- State Departments of Revenue publish rate-change bulletins on a quarterly rhythm. Georgia posts a quarterly rate-change list; the Texas Comptroller publishes quarterly updates including city annexations that move addresses between jurisdictions — a detail manual shops routinely miss.
- The Streamlined Sales Tax Governing Board (streamlinedsalestax.org) requires its ~24 member states to publish machine-readable rate and boundary files quarterly, posted by the first day of the month before each quarter starts — December 1, March 1, June 1, September 1. If your nexus footprint is mostly SST states, this is a free, structured feed built for exactly your problem.
- Avalara publishes free monthly rate tables per state, delivered by email — useful as a cross-check even if you don’t buy the engine.
Europe — VAT.
- The European Commission’s Taxes in Europe database and its annual VAT rates table are the consolidated reference; each member state’s finance ministry gazette is the legal source.
- The rates move more than people think. Recent history: Slovakia restructured in January 2025 (standard to 23%); Estonia went 22% → 24% on July 1, 2025; Romania went 19% → 21% on August 1, 2025 and collapsed its 5%/9% reduced rates into a single 11%; Finland trimmed its reduced rate to 13.5%; the Netherlands moves accommodation from 9% to 21% and Germany moves restaurant food from 19% to 7% in 2026. Note the mid-year dates — a “we review VAT every January” policy would have missed both Baltic changes.
United States — information reporting (1099).
- The IRS publishes each year’s form revisions and electronic-filing specifications around mid-year; changes land in your January filing season. On 12.1 no patch is coming, so the practical options are: export the 1099 data (Payables holds it all — the format is what’s frozen, not the data), and file through a third-party print/e-file service; or maintain the report templates yourself as custom BI Publisher/RDF changes each year.
Base and nexus changes — the ones nobody schedules. Rate percentages are the easy part. The harder-to-catch changes are to what is taxed and where you owe: Illinois dropped its 200-transaction economic nexus test in 2026; Maine began taxing digital audio/video subscriptions January 1, 2026; Colorado and Minnesota impose retail delivery fees ($0.50 per qualifying order, shown as separate invoice lines — which in EBTax terms means a new tax, not a new rate). These arrive as legislation on their own schedules and change your rules and applicability, not just a percentage in a rate table.
The maintenance calendar
Put dates on it or it will not happen. This is the calendar I set up for clients running unsupported instances with manual content:
| When | What | Source |
|---|---|---|
| Dec 1 / Mar 1 / Jun 1 / Sep 1 | Pull SST rate + boundary files and DOR bulletins for every state where you’re registered; diff against your ZX_RATES_B and jurisdiction setup; stage changes in a clone | SST, state DORs |
| Two weeks before each quarter | Enter staged changes (end-date old rate rows, create new ones effective the 1st); test one transaction per changed jurisdiction; run the Financial Tax Register on the clone | — |
| Jan 1 / Apr 1 / Jul 1 / Oct 1 | Changes go live with the quarter; spot-check the first live invoices in each changed jurisdiction | — |
| Monthly (partner-fed shops) | Verify the partner content update actually applied — check the content version and one known-changed rate | Vertex/Avalara/ONESOURCE release notes |
| September–October | Read the IRS 1099 revisions for the coming filing year; decide the filing path (service vs. template maintenance); test before December close | IRS |
| January, plus a mid-year sweep | EU VAT review against the Commission’s table for every registered member state — and subscribe to alerts, because Estonia and Romania both moved mid-year | EC, national gazettes |
| Continuous | One named owner watching nexus/base legislation in your registered states — this is a news-reading job, not a table-updating job | State legislatures, tax press |
A sample year, month by month
The trigger table above tells you why each task exists; this is what it looks like laid onto an actual calendar. Effort assumes a manual-content shop registered in eight to twelve US states plus two EU VAT registrations — scale to your footprint. “Tax owner” is whoever owns the calendar (an AP/AR super-user, a controller, or your support partner); “Analyst” is whoever enters and tests changes.
| Month | Tasks | Owner | Effort |
|---|---|---|---|
| January | Q1 changes went live Jan 1 — spot-check first live invoices per changed jurisdiction. Annual EU VAT sweep against the Commission’s table for every registration. 1099 filing season: generate data, file via chosen path, confirm acceptance | Analyst / Tax owner | 2–3 days |
| February | Quiet month — use it: reconcile ZX_RATES_B against each state’s published current-rate list (annual full-diff, not just changes). Review exemption certificates expiring this year | Analyst | 1–2 days |
| March | Mar 1: pull SST rate + boundary files and DOR bulletins. Diff, build the Q2 change list, stage in clone. Last week: enter changes (end-date + create), test one transaction per changed jurisdiction, run Financial Tax Register on clone, migrate to production | Analyst | 2–4 days |
| April | Apr 1 go-live spot checks. Process Q1 boundary/annexation lists against TCA geography | Analyst | 1 day |
| May | Nexus/base legislation review: sessions in most states have produced their tax bills by now — read what passed in your registered states, flag anything needing a rules change (not just a rate) | Tax owner | 0.5–1 day |
| June | Jun 1: pull Q3 files. Diff, stage, test, migrate — July 1 is the heaviest quarter of the year (fiscal-year starts and voter measures), so start early | Analyst | 3–5 days |
| July | Jul 1 go-live spot checks — the year’s most important ones. Mid-year EU sweep (Estonia’s July 2025 change is why this row exists) | Analyst | 1–2 days |
| August | Half-year audit: sample recalculation of a dozen transactions across modules against published rates; verify partner content versions if fed; review the year’s change tickets for documentation gaps | Tax owner | 1–2 days |
| September | Sep 1: pull Q4 files, stage, test, migrate. Read the IRS’s published 1099 revisions for the coming filing year; decide and book the filing path (service vs. template maintenance) | Analyst / Tax owner | 2–4 days |
| October | Oct 1 go-live spot checks. If maintaining custom 1099 templates: build and test the year’s format changes now, not in December | Analyst | 1–3 days |
| November | EU January-change watch begins (most member-state changes announce by now for Jan 1). Build the Q1 change list early — December is short | Tax owner | 1 day |
| December | Dec 1: pull Q1 files. Stage, test, migrate before the holiday freeze. Confirm 1099 readiness end-to-end with a test file. Publish next year’s calendar with named owners | Analyst / Tax owner | 3–5 days |
Totaled honestly: roughly twenty to thirty analyst-days a year for a footprint of that size, clustered around quarter boundaries — real work, but bounded and predictable, which is the entire point of putting it on a calendar. The mechanics behind every “enter changes” cell — which screens, which objects, what each writes — are covered object-by-object in the supported update paths article.
Two governance rules that make the calendar stick. First, every rate change is a change ticket, with the source bulletin attached — when the auditor asks why your Fulton County rate changed on April 1, the answer is a document, not a memory. Second, no rate is ever updated in place. E-Business Tax is built for date-effective content: the old rate row gets an end date, a new row carries the new percentage, and history stays intact for every transaction that used the old rate. The mechanics of doing that correctly — which tables, which screens, and what to verify — are the subject of the companion piece, The Tables Behind Every Rate Change: An E-Business Tax Update Runbook.
Where this lands
An unsupported EBS instance can absolutely stay tax-compliant. The work is real but it is bounded, it is schedulable, and about eighty percent of it was always yours — Oracle’s departure removed the year-end format patches and the safety net, not the rate feed. What it does demand is that somebody own the calendar above and the skills to apply changes correctly in the ZX data model. That second part — knowing that ZX_RATES_B wants a new effective-dated row and not an update, and being able to write the fix when the engine itself misbehaves with no patch coming — is exactly the work I did for six years at Rimini Street, and it is the work I do now.
Running 12.1 with a tax setup nobody currently owns? Describe the problem — I’ll tell you what shape it’s in and what a quarter of maintenance actually looks like.