The thesis: a classification code is a legal statement, so it belongs in governed data.
Brazil is replacing five consumption taxes with two. The IBS and the CBS were created by Emenda Constitucional 132 of 20 December 2023 and Lei Complementar 214 of 16 January 2025, and they took effect on 1 January 2026 at transitional rates of 0.1 percent and 0.9 percent. The mechanics of that change have been covered thoroughly. The part that lands inside finance systems has had less attention, and it is smaller and more tractable than the headline suggests.
Every item line on every Brazilian electronic fiscal document now carries two new fields: a CST for the IBS and CBS, and a cClassTrib classification code. The technical note describing them puts the point plainly. Each cClassTrib code corresponds to a specific provision of Lei Complementar 214/2025, which makes the taxpayer’s statement about how that line is taxed objective. The table also carries indicators that bind the CST and cClassTrib pair to the validation rules and to the assisted assessment the tax authorities will run from the documents themselves.
That is a different kind of field from a tax code in the older sense. Article 112 of the CBS regulation says the information in the document has declaratory character and constitutes a confession of the amount due. Article 47 of LC 214/2025 makes the buyer’s credit depend on the seller’s debit being extinguished and on a valid electronic document evidencing the operation. One code, chosen once, sets what the seller owes and whether the buyer can recover anything. A decision with that reach is master data, and the encouraging part is that it is entirely knowable: the list is published, it is finite, and it fits in a spreadsheet.
What actually changed, over five days in early August.
Two publications landed close enough together to be easy to conflate, and the difference between them is the whole operating picture for the rest of 2026.
On 30 July 2026 the Receita Federal and the Comitê Gestor do IBS issued Ato Conjunto RFB/CGIBS nº 4, setting the dates from which issuance of each electronic fiscal document becomes mandatory under article 112 of the IBS and CBS regulations. Five days later, on 4 August, version 1.51 of Nota Técnica 2025.002 was published. It struck the 3 August 2026 row out of the implementation schedule for issuers under the normal regime and moved validation rule UB12-10 in production to a future implementation. Reading the technical note as flat text hides this, because the change is recorded as tracked deletions on the page. Reading the page itself makes it unambiguous.
| Date | What happened | Worth knowing |
|---|---|---|
| 1 January 2026 | IBS and CBS take effect. The IBS is charged at a 0.1 percent state rate under article 343 and the CBS at 0.9 percent under article 346, both for the 2026 calendar year. | From this date the new tax information on an electronic fiscal document has legal validity. The technical note says so in its own schedule. |
| 13 January 2026 | Lei Complementar 227 creates the Comitê Gestor do IBS, inserts the accessory obligation penalties at article 341-G, and adds paragraphs 3 and 4 to article 348. | Those two paragraphs are the safety valve. During 2026 a taxpayer assessed for an accessory obligation failure is summoned to remedy it within 60 days, and doing so extinguishes the penalty. |
| 29 and 30 April 2026 | Decreto 12.955 regulates the CBS. Resolução CGIBS nº 6 does the same for the IBS. Article 112 of each requires the electronic fiscal document and defers the start dates to a joint act. | Article 112 also settles what the document is. Paragraph 2 states the information has declaratory character and constitutes a confession of the amount due. |
| 23 June 2026 | The current Tabela de Classificação Tributária do IBS e CBS is published on the NF-e portal. | This is at least the tenth published version of that table since 7 December 2024. It is a reference data feed, not a one-time mapping exercise. |
| 1 July 2026 | Filling the IBS and CBS fields becomes mandatory in the homologação test environment for issuers under CRT 3, the normal regime. | The test environment is where the validation rules bite first, and it is still the cheapest place to find a wrong code. |
| 30 July 2026 | Ato Conjunto RFB/CGIBS nº 4 sets the start dates for mandatory issuance of seventeen categories of electronic fiscal document. | Published on the NF-e portal the following day. The NF-e and NFC-e head the list at 3 August 2026. |
| 4 August 2026 | Nota Técnica 2025.002 version 1.51 is published. It strikes the 3 August 2026 row from the CRT 3 schedule and moves validation rule UB12-10 in production to a future implementation. | The production authoriser will not reject a document for a missing IBS and CBS group yet. Where the group is present, every validation rule still applies to it. |
The live position for an issuer under CRT 3, the normal regime, is the one set out for 1 July 2026 and left standing. In the test environment, filling the IBS and CBS fields is mandatory. In production, filling them is not demanded by a validation rule, and the same schedule says in the same cell that it remains obligatory under current legislation, that documents carrying the fields have the validation rules applied to them, and that the new tax information has legal validity from 1 January 2026.
Receita e Comitê Gestor do IBS explicam uso de notas fiscais em 2026. Ato Conjunto da Receita Federal com o Comitê Gestor do IBS prevê aproveitamento de obrigações em vigência e período sem penalidades
The joint act itself is worth reading in full rather than in summary, because it names seventeen categories of document and the dates are not uniform. The NF-e and NFC-e are the headline, and several document types that finance teams do not think of as invoicing follow within months.
| From | Documents | Worth knowing |
|---|---|---|
| 3 August 2026 | NF-e model 55, NFC-e model 65, CT-e model 57, CT-e OS model 67, MDF-e model 58, GTV-e model 64, NF3e model 66, DC-e model 99, NFS-e Via, and BP-e model 63 outside the semiurban, metropolitan and air passenger categories. | The core goods and transport documents. Most groups with a Brazilian entity are already inside this set. |
| 1 October 2026 | NFS-e for services also subject to ISS that fall outside the digital platform, subitem 1.03, 1.05, 1.09 and 16.01 categories. NFCom model 62. DIR. DeRE contributor table events. | The first NFS-e wave, and the first DeRE events. Services teams get two months less runway than the goods side. |
| 1 December 2026 | The remaining NFS-e categories, including digital platform supplies, subitems 1.03, 1.05, 1.09 and 16.01, intangible goods, condominium charges, and rentals and leases. NFGas model 76. NFAg model 75. BP-e for semiurban, metropolitan and air passenger transport. | Rentals, leases and condominium charges are worth flagging early. They frequently sit outside the billing system that finance thinks of as the invoicing system. |
| 1 January 2027 | Duimp, the single import declaration. | Imports get the longest runway, and they also carry the largest classification surface because the item catalogue on an import rarely matches the sales catalogue. |
Issuers under the Simples Nacional regimes and micro-entrepreneurs sit outside this timetable. Their IBS and CBS taxation begins in 2027 under article 348 of LC 214/2025, and the technical note says guidance for them will come in a later publication. Groups with a mixed supplier base should still expect to receive documents from both populations during 2026, which is an inbound design question rather than an outbound one.
The classification table, read as data.
The most useful thing about this obligation is that the answer set is published. The Tabela de Classificação Tributária do IBS e CBS sits on the NF-e portal under Documentos, Diversos, alongside a companion table of CST indicators. The current version was published on 23 June 2026. Downloading it and looking at the columns is a better first day of an implementation than any summary, including this one.
| What is in it | Detail | Why it matters |
|---|---|---|
| 164 classification codes | The count of cClassTrib rows in the table published on 23 June 2026. | Finite, published, and small enough to review line by line. This is a governable list rather than an open judgement. |
| 18 CST values | From 000 for full taxation through 200, which spans a zero rate and reductions of 30, 40, 50, 60, 70 and 80 percent, then 400 for exemption, 410 for immunity and non-incidence, 550 for suspension, 620 for single-phase taxation, and on to the adjustment codes at 800, 810 and 811. | The CST is the family. The cClassTrib is the specific reason inside that family, and the table binds each one to an article of LC 214/2025. |
| 96 valid on an NF-e | Only 96 of the 164 codes carry indNFe = 1. On the NFC-e it is 40, on the NFS-e 71, and on the Duimp 58. | The same item can need a different code depending on which document it leaves on. Validation rule UB14-25 rejects a code that is not permitted for that document model. |
| 8 group indicators | Each CST row carries indicators for whether the gIBSCBS, gIBSCBSMono, gRed, gDif, gTransfCred, gCredPresIBSZFM, gAjusteCompet and RedutorBC groups are required or forbidden. Zero means not permitted, one means required. | These drive rules UB13-20 through UB13-45. The XML structure of the line is derived from the code, so a wrong code produces a structurally wrong document rather than a merely mispriced one. |
| 83 codes with no rate | Grouped by rate type, 83 of the codes carry no rate at all, 61 use the standard rate, 8 a sectoral uniform rate, 7 a fixed rate and 5 the national reference rate. | Half the table describes situations where nothing is charged and something still has to be declared. Those are the codes an implementation tends to discover last. |
| Reduction percentages on the row | Among the codes that reduce, 26 carry a 100 percent reduction, 23 carry 60 percent, 5 carry 40 percent, and single codes carry 80, 70, 50 and 30 percent. | The reduction lives on the classification row rather than in a separate rate table, so choosing the code chooses the reduction. |
| Validity dates on every row | Each row carries dIniVig and dFimVig fields. All 164 currently open on 1 January 2026 and 161 have no closing date. | The table is versioned by design. An ERP that stores the codes without effective dates cannot reproduce how a document from an earlier month was classified. |
The per document type columns deserve a second look, because they are the ones that break an item-only design. A code valid on an NF-e may be invalid on an NFC-e, and the technical note has a rule for it: UB14-25 rejects a document whose classification code carries a zero indicator for that document model. A wholesale line and a retail line for the same product can need different codes, and the item master has to be able to express that rather than resolve it by exception.
The CST indicator table does something similar at the structural level. Each of the eighteen CST values carries flags saying which XML groups the line must contain and which it must not. Full taxation requires the gIBSCBS group. Immunity and non-incidence forbid it. Single-phase taxation requires a different group entirely. Deferral requires both a rate group and a deferral group. Building the document from those flags rather than from a set of hand-written scenarios turns a whole family of rejections into something the code cannot express.
A reforma tributária e o novo paradigma da não-cumulatividade. Hoje, o sistema pós-reforma começa a ganhar tração: com a publicação das Leis Complementares nº 214, em 2025 e 227, em 2026, de notas técnicas e, finalmente, da parte comum dos Regulamentos do IBS e da CBS
Why the seller’s code is the buyer’s balance sheet.
Indirect tax codes have historically been a seller-side concern. A wrong code was the issuer’s exposure and the recipient’s inconvenience. The new framework connects the two ends of the transaction much more tightly, and it is worth being precise about how.
| Mechanic | What the law says | What it means operationally |
|---|---|---|
| The document is a declaration | Article 112 paragraph 2 of Decreto 12.955/2026 states that the information the taxpayer provides in the electronic fiscal document has declaratory character and constitutes a confession of the CBS amount shown in it. | The classification code is therefore not a formatting field. It is the taxpayer saying, on the record, which article of the law governs this line. |
| The buyer has to ask for it | Article 112 paragraph 1 obliges buyers and recipients who are themselves taxable persons to demand fiscal documents from those required to issue them. | This puts an inbound control on the buyer as well as an outbound one on the seller. Receiving is now a compliance step rather than a filing step. |
| The credit depends on the seller | Under article 47 of LC 214/2025 a taxpayer in the regular regime may appropriate credits when the debits on the operations it purchased are extinguished by one of the methods in article 27, and appropriation is conditioned on the operation being evidenced by a valid electronic fiscal document. | A seller who classifies a line wrongly puts the buyer’s credit at risk, not only their own position. This is the reason to treat classification as a customer-facing data quality question. |
| Extinction has five routes | Article 27 lists offset against credits, payment by the taxpayer, collection at financial settlement of the operation under the split payment mechanism, collection by the buyer, and payment by whoever the law makes responsible. | Split payment means the collection event can be tied to the money movement rather than to a monthly return, which is what makes the document data time-critical. |
| IBS and CBS never mix | Article 47 paragraph 1 requires appropriation to be made separately for IBS and for CBS, and prohibits offsetting IBS credits against CBS due or CBS credits against IBS due in any circumstance. | Two parallel credit ledgers from the same document line. A design that carries a single tax credit balance will not survive first contact. |
| Some credits reverse | Article 47 paragraph 6 requires the buyer to reverse an appropriated credit if the purchased good perishes, deteriorates, or is stolen or lost. | Classification code 410030 exists for exactly this, and validation rule UB14-70 ties it to debit note type 07, stock loss. The reversal has a named document shape. |
Article 27 is the piece that makes timing matter. It lists five ways a debit can be extinguished, and one of them is collection at the moment the operation is settled financially, the split payment route. When the collection event can attach to the payment rather than to a monthly return, the data on the document stops being a filing input and starts being part of the transaction. That is a good argument for getting classification right in the source system rather than correcting it in a tax engine downstream.
There is a second, quieter consequence for the ledger. Article 47 paragraph 1 forbids offsetting IBS credits against CBS due and CBS credits against IBS due, in any circumstance. Two credit balances arise from the same document line and never meet. Systems that carry a single recoverable tax balance per entity will need two, and that is a schema decision best made while the balances are still measured in tenths of a percent.
O CFC publicou a Orientação Técnica nº 1/2026 com diretrizes para o tratamento contábil do IBS e da CBS, apoiando contadores e empresas na implementação da Reforma Tributária.
The data model this asks for.
None of this needs a new product. It needs the classification decision to be a record with provenance instead of a value on a screen. The fields below are the ones that make the difference between a determination you can explain in 2029 and a code somebody typed.
item_tax_classification
The cClassTrib code held against the item, with the CST it belongs to. Not a free text field and not a default: rule UB14-20 rejects a cClassTrib that is incompatible with the CST supplied alongside it.
operation_context
The code is decided by the item and the operation together. A transfer, an export, a return, a donation and an ordinary sale of the same item can land on different codes, so the determination key is item plus operation type plus destination rather than item alone.
document_model_scope
Which document types the code is valid on, carried from the indNFe, indNFCe, indNFSe, indCTe, indDUIMP and related columns. This is the field that prevents a code that is fine on an NF-e from being sent on an NFC-e.
legal_basis
The LC 214/2025 article the code points at, copied from the table rather than typed. An auditor asking why a line was exempt should get an article number from the record, not from a person.
effective_from and effective_to
Taken from dIniVig and dFimVig. Classification is a point-in-time fact, and a document issued in March has to be explainable against the table as it stood in March.
table_version
The publication date of the classification table this determination was made against. The table has been republished at least ten times since December 2024, and without a version stamp a reclassification is indistinguishable from an error.
required_groups
The gIBSCBS, gIBSCBSMono, gRed, gDif and related group indicators resolved from the CST. Deriving the XML structure from the code, rather than hand-building it per scenario, is what stops rules UB13-20 through UB13-45 from firing.
adjustment_document_type
The tpNFDebito or tpNFCredito value a code is allowed to accompany. Rules UB14-60, UB14-70 and UB14-80 pair specific codes to specific note types, so the adjustment path belongs in the model rather than in a procedure document.
A classification determination with its provenance attached
{
"determination_key": {
"item_id": "SKU-88421",
"operation_type": "SALE_DOMESTIC",
"destination_uf": "SP",
"document_model": "NFE_55"
},
"resolved": {
"cst_ibs_cbs": "200",
"cst_description": "Aliquota reduzida em 60%",
"cclasstrib": "200030",
"cclasstrib_name": "Venda dos dispositivos medicos (Anexo IV)",
"legal_basis": "LC 214/2025, art. 131",
"rate_type": "Padrao",
"p_red_ibs": 60,
"p_red_cbs": 60
},
"required_groups": {
"gIBSCBS": true,
"gRed": true,
"gIBSCBSMono": false,
"gTransfCred": false
},
"document_model_scope": {
"indNFe": 1,
"indNFCe": 1
},
"provenance": {
"table_version": "2026-06-23",
"effective_from": "2026-01-01",
"effective_to": null,
"determined_by": "rule",
"reviewed_by": "tax.br@example.com",
"reviewed_at": "2026-08-11"
}
}Two fields in that record carry more weight than they look like they should. The table_version stamp is the one that makes a reclassification explainable: when the published table moves, and it has moved at least ten times since December 2024, a determination carrying the version it was made against is a fact rather than a mystery. And the determination_key being wider than the item is what stops the design from being quietly wrong on transfers, returns and retail flows, where the published rules genuinely do give a different answer for the same product.
The legal_basis field looks like documentation and behaves like a control. The published table already carries the article reference for every code, so copying it onto the determination costs nothing at build time and answers the only question an auditor is going to ask. A classification that can cite its own article is defensible without anyone having to remember why it was chosen.
Implementation checklist.
Establish which of your Brazilian document types are already inside the obligation. The NF-e and NFC-e began on 3 August 2026, the first NFS-e wave and the NFCom and DIR follow on 1 October, most remaining services on 1 December, and the Duimp on 1 January 2027. Groups tend to know their NF-e position and to be vaguer about rentals, condominium charges and intangible supplies, which are named explicitly in the joint act.
Load the published classification table as data rather than reading it as a document. All 164 rows, all 18 CST values, the group indicators, the per document type flags, the reduction percentages, the validity dates and the article references. Everything an implementation needs to answer a classification question is in that file, and typing a subset of it into a configuration screen loses the columns that matter later.
Stamp the table version on every determination. The table has been republished at least ten times since December 2024. Without the version on the record, nobody can tell a code that changed because the table changed from a code that changed because someone edited it.
Set the determination key wider than the item. Item plus operation type plus destination plus document model is the minimum that reproduces the published rules. A determination keyed on the item alone will be right most of the time and silently wrong on transfers, returns and exports.
Derive the XML group structure from the CST indicators instead of hand-coding scenarios. The indicator sheet says plainly which groups each CST requires and which it forbids, and building the document from those flags turns a class of rejections into an impossibility.
Use the homologação environment as the rehearsal it is. Filling the fields there has been mandatory since 1 July 2026 and the validation rules apply in full. Every rejection found in the test environment during 2026 is a rejection that does not happen in production later.
Keep sending the fields in production while the rejection rule is deferred. Where the group is present, all the validation rules run against it, so a voluntarily complete document is a fully checked document. That is a free correctness signal for as long as the gate stays down.
Give inbound documents the same attention as outbound ones. Article 112 paragraph 1 obliges the buyer to demand the document, and article 47 makes the credit depend on it. A supplier whose classification is wrong is a working capital problem on your side of the transaction.
Model IBS and CBS as two separate credit balances from the first design conversation. Article 47 paragraph 1 forbids offsetting one against the other in any circumstance, and retrofitting a split into a single tax credit ledger is expensive in a way that is easy to avoid now.
Write down who owns a classification decision and how it gets reviewed. The code cites an article of the law, so the reviewer needs to be someone who can defend that citation. Naming that person, and recording the review on the item, is what turns a spreadsheet exercise into a control.
Sequence it against what is already published. Loading the table, widening the determination key and stamping the version are internal changes that need nothing from a tax authority or a vendor, and they can start this month. The homologação rehearsal and the production fill-while-the-gate-is-down step both produce free correctness signals, so they belong early rather than late. The inbound validation work depends on what suppliers actually send, which is a reason to build the check now and let the findings accumulate.
Constructive failure modes to design around.
Reading the deferred rejection rule as a deferred obligation. Ato Conjunto RFB/CGIBS nº 4 set the issuance obligation and version 1.51 of the technical note moved only the production rejection. The technical note is explicit that filling the fields remains obligatory under current legislation and that the information has legal validity from 1 January 2026. The gate came down. The requirement did not.
Waiting for the enforcement date and losing the rehearsal. The 2026 arrangement is unusually forgiving: amounts collected are offset against existing contributions under article 348, paragraph 1 waives the collection for taxpayers meeting their accessory obligations, and paragraphs 3 and 4 give 60 days to remedy an accessory failure before a penalty stands. That is a year built for finding mistakes cheaply, and it is finite.
Treating classification as a billing screen field. The code points at an article of the law and the document is a confession of the amount due. A decision of that weight defaulted at invoice time, by whoever happens to be releasing the order, is a control gap dressed as a usability improvement.
Mapping the old codes onto the new ones and stopping there. The CST and cClassTrib pair is a different question from the ICMS, IPI, PIS and COFINS codes it eventually replaces, because it names a legal basis rather than a tax treatment. A crosswalk is a useful starting draft and a poor finished answer.
Assuming one code per item. Only 96 of the 164 codes are valid on an NF-e and only 40 on an NFC-e, and the adjustment codes are tied to specific debit and credit note types. Retail and wholesale flows for the same product can require different codes, and the item master has to be able to say so.
Ignoring the codes that carry no rate. Eighty-three of the 164 describe situations with no rate at all, covering immunity, non-incidence, suspension, exemption and deferral. These are the lines where nothing is charged and the classification still has to be right, and they are usually the last ones an implementation gets to.
Leaving the classification table as a static copy. Rows carry validity dates, the table gains and loses codes between publications, and three rows in the current file already carry an end date. A refresh path with a version stamp is a small piece of engineering that avoids a large piece of archaeology.
Scoping the work to the NF-e alone. The technical note introduced a shared type definition precisely so that the IBS and CBS structure is the same across every electronic fiscal document. Services, transport, energy, gas, water, imports and the DeRE declaration all land within the following five months.
The thread running through most of these is a single assumption: that an enforcement gate and a legal requirement are the same thing. They usually are, which is why the assumption is reasonable and why the current position in Brazil is worth stating carefully. For the rest of 2026 they have come apart, deliberately, and the space between them is where the cheap version of this work lives.
What to ask ERP and tax engine vendors now.
Can the system hold a tax classification determination keyed on item, operation type, destination and document model together, rather than a single code held against the item?
Does a determination record the classification table version it was made against, and can a document issued months ago be re-explained against the table as it stood then?
Are the cClassTrib validity dates honoured, so a code that closes on a date stops being selectable from that date without anyone editing configuration?
Is the XML group structure derived from the published CST indicators, or is each scenario hand-built and therefore hand-maintained?
Can the platform refuse a code that is not valid for the document model being issued, before the document reaches the authoriser?
Are IBS and CBS carried as two separate credit balances with no path to offset one against the other?
Does the inbound document process validate a supplier’s classification and flag a line whose code puts a credit at risk, rather than posting whatever arrives?
Can the adjustment path pair a debit or credit note type with the classification codes the rules allow alongside it?
Is there an audit trail showing who reviewed a classification, when, and against which article of LC 214/2025?
A platform that already models tax determination as a versioned rule set with provenance has most of what this needs, and the Brazilian requirement is a good test of whether that claim is real. Ask during a roadmap review rather than during a go-live, and the answers arrive while there is still time for them to change something.
Practical takeaway.
The IBS and CBS classification code is one of the more governable obligations a finance systems team will be handed. The answer set is published, finite and machine readable. The rules that check it are written down and numbered. The legal basis for every code is a column in the same file. And for the remainder of 2026 the production gate is down while the obligation, the legal validity of the data, and the full validation rule set all stand, which means every document sent complete is checked for free. Load the table, widen the determination key past the item, stamp the version on the record, and put the article reference where an auditor can find it. When the gate comes back up, a team that did this changes nothing.
Sources.
- Portal Nacional da NF-e: Nota Técnica 2025.002-RTC version 1.51, published 4 August 2026, the technical note that defines the IBS, CBS and Imposto Seletivo layout, the cClassTrib and CST validation rules and the implementation schedule. Downloaded and read page by page, including the tracked changes that a text extraction flattens away
- Portal Nacional da NF-e: Ato Conjunto RFB/CGIBS nº 4, de 30 de julho de 2026, published 31 July 2026, setting the start dates for mandatory issuance of each electronic fiscal document under article 112 of the IBS and CBS regulations
- Portal Nacional da NF-e, Documentos, Diversos: the Tabela de Classificação Tributária do IBS e CBS published 23 June 2026 and the Tabela de Indicadores de CST do IBS e CBS, the two published reference tables every count in this article was taken from directly
- Planalto: Lei Complementar nº 214, de 16 de janeiro de 2025, source of article 27 on how a debit is extinguished, article 47 on when a buyer may appropriate a credit, article 62 on adapting the document authorisers, and articles 343, 346 and 348 on the 2026 transition
- Planalto: Lei Complementar nº 227, de 13 de janeiro de 2026, which created the Comitê Gestor do IBS, inserted the accessory obligation penalties at article 341-G of LC 214/2025, and added the 2026 cure window at article 348 paragraphs 3 and 4
- Planalto: Decreto nº 12.955, de 29 de abril de 2026, the CBS regulation, source of article 112 requiring an electronic fiscal document and stating that the information in it has declaratory character and constitutes a confession of the amount due
- Portal Nacional da NF-e: the XML schema packages implementing Nota Técnica 2025.002, including the shared DFeTiposBasicos definition that carries the IBS and CBS structure into every electronic fiscal document rather than into the NF-e alone
Every date, count, article reference and validation rule number above was taken from the primary document rather than from a summary. Nota Técnica 2025.002 version 1.51 was downloaded and its schedule and validation rule pages were read as pages, which matters here: a plain text extraction of that file flattens the tracked deletions and reports the struck 3 August 2026 production milestone as though it were still in force. Several secondary reports say exactly that. The counts describing the classification table were computed directly from the published spreadsheet of 23 June 2026 and its CST indicator companion, rather than quoted from anyone. Lei Complementar 214/2025, Lei Complementar 227/2026 and Decreto 12.955/2026 were read on Planalto, and the articles named here are the articles quoted. Three public posts on X are cited, from JOTA on 12 January 2026, ConJur on 30 May 2026 and Portal Contábeis on 21 July 2026, each verified as live and public before being quoted. Posts from the Receita Federal account covering the same ground could not be verified from a logged out session and are therefore not cited, and nothing has been invented to fill the gap. The determination record shown above is a worked example of the shape being described and is not an extract from any customer system. Where the published material describes a future implementation without a date, such as the deferred production rejection rule, it is described that way here.