Fiscal Operations
A Fiscal Operation is the nature of a transaction — is this a domestic sale, a sale across a state line, an export? It’s a small idea with big consequences, because in some countries the same goods are taxed completely differently depending on the answer.
The defining trait: a Fiscal Operation is computed, not chosen. The engine works it out from where the seller and buyer are — comparing their jurisdiction codes — rather than asking a user to pick. That keeps it objective and audit-safe: nobody can mis-tag a transaction to get a different tax.
Access you'll need. Setting up and maintaining fiscal operations requires the Accounting Admin v2 or Accounting Controller v2 permission set. The Accounts Payable v2, Accounts Receivable v2, and Read Only v2 sets can view them but not change them.
How it’s derived
The engine compares the seller’s and buyer’s jurisdiction codes (covered in Tax Jurisdictions) and classifies the transaction purely from the text:
| Seller vs buyer | Classified as | Example |
|---|---|---|
| Same country, same state | Intrastate | BR-SP → BR-SP |
| Same country, different state | Interstate | BR-SP → BR-RJ |
| Different country | Export | GB → FR |
The engine then finds the matching Fiscal Operation record (a Sale operation marked interstate or not, or an Export operation) and feeds it to rule matching. Sales and Purchase Invoices also carry a Fiscal Operation field, so a business can pin an operation explicitly on a document where it must be stated — for example Brazil’s CFOP on an electronic invoice — but the normal path is automatic derivation.
The fields — with Brazil values
Brazil is the right lens here, because the UK doesn’t use fiscal operations at all (more on that below). Here is every field with a real Brazilian value — the interstate manufactured-goods operation, whose code is a CFOP:
| Field | Type | Required | What it’s for | 🇧🇷 Example value |
|---|---|---|---|---|
| Code | Text · External ID | Yes | Match/seed key — in Brazil this is the CFOP | BR-6101 |
| Transaction Type | Picklist | Yes | Sale / Purchase / Sales Return / Purchase Return / Transfer / Import / Export / Intercompany | Sale |
| Is Interstate | Checkbox | No | Crosses a state line — the key flag for ICMS / IGST | true |
| Country Scope | Lookup (country jurisdiction) | No | Limits the operation to one country | BR |
| Description | Text Area | No | Plain-language meaning (shown on selection) | Sale of manufactured goods (interstate) |
| Is Active | Checkbox | No | Off → excluded from matching | true |
| Notes | Long Text | No | CFOP description, scenarios | NF-e CFOP 6.101 |
Brazil: where Code is the CFOP
Brazil’s tax documents (NF-e) legally require a CFOP — a four-digit code that classifies every operation. REDA models each CFOP as a Fiscal Operation whose Code carries it. The seed ships six:
| Code (CFOP) | Operation | Interstate? |
|---|---|---|
BR-5101 | Sale of manufactured goods | No (intrastate) |
BR-6101 | Sale of manufactured goods | Yes |
BR-5102 | Sale of purchased goods | No |
BR-6102 | Sale of purchased goods | Yes |
BR-6108 | Sale, Simples Nacional | Yes |
BR-5405 | Sale, ICMS Substituição Tributária | No |
Brazilian CFOPs follow a convention the codes echo: a 5 prefix is
intrastate, a 6 prefix is interstate — which lines up exactly with
the Is Interstate flag the engine reads.
In practice: the switch in action
Take the same São Paulo manufacturer selling the same goods, and change only the customer’s location:
| Buyer | Derived operation | Rules that fire |
|---|---|---|
| In São Paulo | Intrastate (BR-5101) | ICMS 18% internal — no DIFAL |
| In Rio de Janeiro (end consumer) | Interstate (BR-6101) | ICMS 12% interstate + DIFAL 8% + FCP 2% (DIFAL/FCP fire for non-contributor buyers) |
The interstate ICMS and DIFAL rules carry Fiscal Operation = BR-6101 as a matching condition, so they only fire when the engine derives an interstate sale. Flip the buyer back to São Paulo, the engine derives intrastate, those rules don’t match, and the 18% internal rule takes over. One field on the customer — their jurisdiction — drives the whole thing.
Guardrails & setup
- Code is uppercase, no spaces — two validation rules enforce it (it’s an external ID, like jurisdiction and tax-type codes).
- Seeded for countries that need them. Brazil and India packs include fiscal operations; simple-VAT packs (UK) don’t. The Tax Seeding Wizard creates the right set per country.
- Is Interstate is the field that does the work for Brazil/India rate splits — set it correctly on each operation.
- Deactivate, don’t delete obsolete operations, to keep historical invoices intact.
Where to go next
- Tax Rules — where fiscal operations gate the rule.
- Tax Types — the taxes a fiscal operation selects.
- Brazil (ICMS, IPI, PIS/COFINS) — fiscal operations in real use.
- How Tax Calculates on a Document — how the operation is chosen at runtime.
Frequently asked questions
Normally no — the engine derives it from the seller’s and buyer’s jurisdictions, so it can’t be mis-tagged. Invoices do carry a Fiscal Operation field for cases where an operation must be stated explicitly (such as recording the exact CFOP on a Brazilian NF-e), but the default is automatic.
No, that’s correct. UK VAT doesn’t vary by transaction nature, so its rules leave the fiscal-operation condition blank and always match. Fiscal operations are only needed where the tax depends on interstate/intrastate/export — Brazil and India.
The two jurisdiction codes. Same country and same state → intrastate; same country, different state → interstate; different country → export. So getting the Tax Jurisdiction right on the customer’s Account and your Entity is what makes the derivation correct.
Because Brazil legally requires a CFOP on every fiscal document. Modelling each CFOP as a Fiscal Operation (with the CFOP as its Code) means the right code is recorded and the right rules fire — the 5/6 prefix even mirrors the Is Interstate flag.
Was this article helpful?