ERP Protheus · Tax Reform

Fiscal vs. Financial Rules in the Protheus Tax Configurator

Where the fiscal side ends and the financial side begins in Protheus. Why mixing them produces a correct invoice with the wrong receivable — and how to separate them.

Jun 10, 2026 8 min read Tax Configurator
Vanquish CodeJun 10, 20268 minTax Configurator
Share:

A scenario that will repeat a lot in 2026: the invoice comes out perfect — IBS and CBS broken down, CST and cClassTrib correct — but the receivable comes out with the wrong amount, or the due date is off, or cash flow doesn't reconcile. The problem is almost never the tax calculation. It's the boundary between what is a fiscal rule and what is a financial rule inside Protheus.

In the Tax Configurator (Configurador de Tributos), these two layers meet — but they are not the same thing. Knowing where one ends and the other begins is what separates an implementation that "issues invoices" from one that keeps cash correct.

What a Fiscal Rule Is in the Tax Configurator

The fiscal rule answers one question: how much tax applies and how it is classified and recorded. In Protheus it lives inside the Tax Configurator (which replaces the TES for IBS/CBS) and is made of:

  • Product and participant profiles — define which operations the rule applies to.
  • Calculation base rule — what enters and leaves the base (freight, insurance, discounts).
  • Rate and calculation rule — the percentage and formula that produce the tax amount.
  • CST and cClassTrib — the tax classification that goes on the NF-e. See how to import the cClassTrib in Protheus.
  • Bookkeeping rule — what feeds the ledgers and accessory obligations (SPED).

The fiscal rule's output is the tax broken down on the invoice and correct assessment data. It is the compliance layer. If you're leaving the TES now, start with the TES-to-Tax-Configurator migration guide.

What a Financial Rule Is (and Why It Doesn't Live in the Configurator)

The financial rule answers another question: how that amount becomes money to receive or pay. It is not in the Tax Configurator — it lives in the financial flow (receivables/payables, the order's financial sheet, payment terms) and covers:

  • Receivable composition — whether the tax is included in the amount due (with IBS/CBS "on top", it's added).
  • Payment terms and due dates — in how many installments and when the amount (tax included) is billed.
  • Financial nature and allocation — how the receivable is classified and split.
  • Cash-flow impact — what actually enters cash, and when.
💡 A simple rule: fiscal = how much and how to classify/record (Tax Configurator). Financial = how it becomes a receivable and cash (financial module). Different layers of the same process.

Where the Two Worlds Meet: from Calculation to Receivable

The contact point is the sales order's financial sheet (and the inbound document's tax tab). That's where the amount calculated by the fiscal rule "crosses over" to finance: the IBS/CBS set in the Configurator is broken down on the financial sheet and then composes — or not — the receivable.

That crossover is exactly where most errors are born: the fiscal rule is right, the calculation is right, but the financial parameterization doesn't treat the add-on as expected. The invoice is correct; the receivable is not.

A fiscally correct invoice does not guarantee a correct receivable. They are two separate validations — and both must pass before go-live.

The Most Common Mistakes When Mixing Fiscal and Financial

  • Assuming the Configurator handles cash: you set up the calculation and assume the receivable comes out right "as a consequence". It doesn't.
  • Solving a financial issue inside the Configurator: forcing the receivable composition by changing the fiscal base distorts assessment and SPED.
  • Ignoring the "on top" add-on: the receivable keeps the merchandise value without IBS/CBS — and reconciliation breaks.
  • Due dates left unreviewed: with a higher amount per receivable, payment terms and cash flow need revisiting.

IBS/CBS "On Top" and Split Payment: the Boundary Got More Critical

Before the reform, many taxes were embedded in the price, and the gap between fiscal and financial went unnoticed. With IBS and CBS broken down on top, the receivable is no longer equal to the merchandise value — the financial rule must treat that add-on explicitly.

From 2027, split payment deepens the split: part of the payment goes to the tax authority at settlement, so what actually enters cash (the net) differs from the receivable. Those who organize the boundary well today arrive at 2027 prepared.

How to Separate It Correctly — Checklist

  • Calculation, rate, CST, cClassTrib and bookkeeping only in the Tax Configurator
  • Receivable composition, payment terms and nature in the financial flow
  • Check the IBS/CBS broken down on the order's financial sheet
  • Validate the receivable amount with the "on top" tax included
  • Review due dates and cash flow with the new amount per receivable
  • Test invoice and receivable together — not just issuance
  • Anticipate split payment (net vs gross) in the cash projection

How Vanquish Code Organizes Fiscal and Financial in Your Protheus

Vanquish Code is a full-service IT company with expertise in Protheus ERP, databases and Agentic AI. On the fiscal-financial boundary, we put each decision in the right layer and validate both ends: free diagnosis, fiscal rules in the Configurator, financial rules in the financial module, and integrated tests that check NF-e and receivable in the same scenario — backed by our Protheus support team.

Conclusion: Each Rule in Its Layer

Most "right invoice, wrong money" problems are not bugs — they're a poorly defined boundary between fiscal and financial rules. Keeping calculation and bookkeeping in the Tax Configurator and receivable composition in finance, validating both ends, ensures compliance and cash predictability. Vanquish Code organizes this separation end to end.

Read in:🇧🇷 Português🇺🇸 English🇪🇸 Español

Fiscal and financial aligned in your Protheus

Vanquish Code places each rule in the right layer and validates invoice and receivable together. Start with a free diagnosis of your environment.

Talk to our specialists →

Related articles

Protheus Tax Configurator: Migrate from TES without errors
Step-by-step guide to replacing the TES with the Tax Configurator in Protheus safely.
Protheus Fiscal Homologation: Go-Live Checklist
What to validate in Protheus — IBS, CBS, Tax Configurator and accounting integration — before go-live.
Split Payment in Brazil Tax Reform and Protheus
How split payment impacts financial flow and what to prepare in Protheus for 2027.

Frequently asked questions

The fiscal rule (Tax Configurator) defines how the tax is calculated and classified — base, rate, CST, cClassTrib and bookkeeping, what goes on the NF-e and SPED. The financial rule defines how that value becomes a receivable/payable — composition, payment terms, due date and cash flow. Different layers of the same process.

No. It calculates, classifies and breaks down the tax on the order's financial sheet, but composition, due date and nature depend on the financial flow. Treating the fiscal rule as if it solved finance is a common cause of wrong receivables or cash.

Because the receivable now differs from the merchandise value. If the financial rule ignores the add-on, the receivable, cash flow and reconciliation diverge — even with a correct invoice.

We map each decision to the right layer — calculation and bookkeeping in the Configurator; receivable composition and cash in finance — and validate both together, checking NF-e and receivable in the same scenario. The initial diagnosis is free.