ERPRFC004 — Brazilian Fiscal Engine

• *tatus:*Stub
• *ate:*20260412
• *uthor:*Koder Team
• *epends on:*erp-RFC-000-architecture-overview.md, kompass-RFC-001-identity-and-org-unification.md, erp-RFC-002-bpm-workflow-engine.md
• *hase:*5 (Brazilian fiscal engine)
• *locked by:*kompass-RFC-001 (identity), ideally erp-RFC-002 (BPM, for approval chains)
• *elated:*platform/billing (existing — billing only, not fiscal)

---

Summary

A module owning Brazilian fiscal compliance: NFe (produto), NFSe (serviço), SPED (fiscal, contábil, contribuições), DRE, fluxo de caixa, conciliação bancária, contas a pagar, contas a receber, plano de contas, apuração de impostos (ICMS, PIS, COFINS, ISS, IRPJ, CSLL). This is the heaviest module of the ERP track because of regulatory surface area — every Brazilian fiscal rule is versioned by state, municipality, legal regime (Simples, Lucro Presumido, Lucro Real), and activity code (CNAE). The engine compartmentalizes the churn in platform/fin-br/ specifically so it does not pollute the rest of the stack.

This is *ot*a "Koder accounting software." It is the fiscal layer that every other engine touches when money has to be declared to the Brazilian tax authorities. Licitação hands off to finbr when a contract payment is due. Travel hands off when perdiem reimbursement needs to be fiscalized. HR hands off when payroll produces a DIRF entry. Billing hands off when an invoice becomes a NF-e.

Name decision

*eferred.*This engine's name is the most constrained of the track because it must project Brazilianspecific competence without being so BRbranded that it locks Koder out of other jurisdictions later. Candidates:

• fin-br (descriptive, explicit, Brand would be low but honest)
• fisco (pt: tax authority; Brand 77 per scratch calculation, but ambiguous with "the IRS itself")
• fiscus (latin root; Brand 83)
• tributus (latin: tribute)
• tributo (pt/latin)
• publicus (generic)
• livro (pt: book; as in "livro-razão", the accounting ledger)
• razao (pt: general ledger; too specific)

The Brazilian extension layer convention from erp-RFC-000 says regulatory code lives in a br/ subdirectory of whatever horizontal engine owns the core concept. If accounting and billing are considered horizontal, the BR fiscal layer could live in platform/billing/br/ and platform/accounting/br/ (if a sibling platform/accounting is created). The alternative is a dedicated platform/fin-br/ top-level engine.

The RFC when promoted will decide between these two placements. Current lean: *edicated top-level engine*because Brazilian fiscal law is dense enough to deserve its own module, and trying to split it between generic accounting and billing engines creates coordination overhead without saving code.

Scope

In scope (full)

Fiscal documents

• *Fe*(Nota Fiscal Eletrônica de Produto, modelo 55) — emission, cancellation, inutilização, correção (CCe).
• *FS-e*(Nota Fiscal de Serviço, municipal) — emission against each of ~5570 municipal portals. Most follow one of ~10 major software vendors; the engine has pluggable adapters.
• *FCe*(Nota Fiscal de Consumidor Eletrônica, modelo 65) — retail pointof-sale.
• *T-e*(Conhecimento de Transporte Eletrônico) — only if Crescer/Vivver moves goods or contracts transport services at a scale that requires it.
• *DF-e*(Manifesto de Documentos Fiscais) — probably not needed for Crescer/Vivver.
• *ANFE, DANFSe, DACTE*— printable representations, PDF and A4.

Apuração de impostos

• *imples Nacional*— for tenants under the regime; DAS generation, cálculo por anexo, anexo IIIIIIIVV/V-A.
• *ucro Presumido*— PIS/COFINS cumulativos, ISS presumido, IRPJ por lucro arbitrado.
• *ucro Real*— PISCOFINS nãocumulativos, EFDContribuições, EFD-ICMSIPI, ECD, ECF.
• *CMS*— apuração mensal com base nas notas de entrada/saída, ST, DIFAL.
• *SS*— apuração municipal, retenção na fonte.
• *RPJ / CSLL*— apuração trimestral ou anual.
• *IS/COFINS*— apuração mensal.

SPED

• *PED Fiscal (EFD-ICMS/IPI)*— mensal, entrega até o 20º dia do mês seguinte.
• *PED Contribuições (EFD-Contribuições)*— mensal, PIS/COFINS.
• *PED Contábil (ECD)*— anual, livro diário e razão.
• *PED ECF*— anual, apuração IRPJ/CSLL.

Accounting core

• *lano de contas*— tenant-configurable, following standards (Padrão Contábil, Plano Referencial).
• *ivro Diário, Razão*— per regime and tenant.
• *RE*(Demonstração do Resultado do Exercício) — configurable structure per tenant.
• *alanço Patrimonial*
• *luxo de caixa*— direto e indireto.
• *onciliação bancária*— matching bank statements against internal ledger.

Operational

• *ontas a pagar*— fornecedores, obrigações tributárias, folha.
• *ontas a receber*— clientes, inclusive órgãos públicos via platform/edictus hand-off.
• *luxo de caixa projetado*

Out of scope (MVP slice)

The full scope above is obviously not a MVP. A realistic MVP slice:

1. NFe + NFSe emission for CrescerVivverKoder's actual use cases.
2. Simples Nacional DAS calculation (the regime Crescer/Vivver currently operate under, to be verified).
3. Contas a pagar and contas a receber operational layer.
4. Handoff contracts from platform/edictus and platform/billing.

Everything else is phased post-MVP as regulatory needs arise.

Dependencies