Most AP tax handling is about what the vendor billed. Self-assessed use tax is about what the vendor didn't bill — and that inversion is exactly why it trips up automation.
When a supplier sells a taxable good or service but doesn't charge tax on the invoice — often because they're out of state, or simply made an error — the buyer doesn't get a free pass. If tax is legally owed, the buyer has to self-assess it: calculate the liability themselves, accrue it, and report it to the tax authority. For public-sector finance teams, this isn't optional. Government entities are under particular scrutiny to capture every use-tax obligation, because the money is public and the reporting is audited.
Use tax vs. sales tax: the distinction that matters
The two taxes look similar on a financial statement but behave completely differently in an AP workflow:
| | Sales tax | Use tax | |---|---|---| | Who charges it | The vendor, on the invoice | Nobody — the buyer self-assesses | | Dollar amount | Printed on the invoice; entered and split into its own lines | Not on the invoice; calculated by the ERP from the line amount and configured rate | | Where it lives | Part of the vendor's total | An accrual on the buyer's side; the vendor total is unchanged |
That third row is the crux. With sales tax, you're recording a number the vendor gave you. With use tax, there is no number on the invoice — the obligation has to be recognized by a human who knows the purchase is taxable, then calculated by the ERP. The invoice total the vendor sent never changes; the use tax is a separate liability the organization books against itself.
A practical consequence: on any given invoice, the two are mutually exclusive. If the vendor charged sales tax, there's no use tax to self-assess. Use tax only enters the picture precisely when sales tax is absent but should not have been.
Why this is a capture problem, not a calculation problem
Oracle EBS is perfectly capable of calculating use tax. Point it at a line with the right tax classification code and Oracle's tax engine computes the liability from the line amount and the configured rate, then rolls it into the entity's use-tax report. You don't want your AP automation reinventing that — Oracle already does it well, and the rates are configured and maintained on the Oracle side.
The hard part is upstream. Someone has to decide, per line, that use tax applies — and that decision has to be captured before the invoice posts, so the right tax classification code is attached when Oracle imports it. That judgment can't be automated away: it depends on knowing whether the purchase is taxable and whether the vendor failed to bill it. It's an AP specialist's call.
If your automation has no field for that flag, you get the same broken pattern that haunts every "the ERP will handle it" assumption: invoices import clean, and then an AP specialist has to remember to open each affected invoice back up in Oracle and manually add the tax classification. Miss one and the use-tax liability simply never gets recorded — an audit finding waiting to happen, with no trail showing the step was skipped.
Capturing the flag in the workflow
The right place to capture use tax is per line, during AP review, inside the approval workflow:
- A use-tax indicator on each invoice line, visible to everyone in the workflow for transparency but editable only by the authorized AP role — the people qualified to make the call.
- No dollar entry. The user is flagging that tax applies, not how much. The automation never calculates or stores a use-tax amount; that's Oracle's job. This keeps a clean single source of truth for the actual liability.
- Mapping the flag to the correct tax classification code on submission, so Oracle's tax engine has exactly what it needs to calculate and report. The codes already configured in the organization's Oracle AP setup are reused as-is — the automation passes the existing code, it doesn't set rates.
- An audit trail recording when the flag was set and by whom — closing the accountability gap the manual post-import step always leaves open.
The result: the invoice total stays exactly what the vendor sent, the use-tax accrual is recognized automatically on the Oracle side, and nobody has to re-open invoices after import to chase a compliance obligation by memory.
Why public-sector AP can't skip this
Self-assessed use tax is a niche requirement until you're a public entity — and then it's a recurring liability you're legally bound to capture and report. It's one more reason fund accounting breaks generic AP automation: commercial tools assume the vendor's invoice is the whole tax story, when for government and education finance teams it often isn't.
EZ Cloud captures the per-line use-tax flag inside the approval workflow and passes the correct tax classification code into Oracle on submission, letting Oracle's tax engine do the calculation it's built for. It's part of how we approach K-12 AP on Oracle EBS and the Education on Oracle EBS solution.
If your AP team is still re-opening imported invoices to flag use tax by hand, that's a compliance risk and an automation gap in one. It's exactly the kind of detail our Oracle EBS & Fusion integration was designed to handle.