Brazil makes you emit dozens of fiscal documents to dozens of authorities — each with its own layout, signature and deadline — and then move the money on separate rails. dbr-gov collapses all of it into one integration: emit any document, move money on any rail, and arrive at the Tax Reform already ready.
The foundation
Each obligation's official manuals and layouts are the reference of truth. We model each one once, behind one contract — the dialect of each authority never reaches your code.
NF-e, NFC-e, NFS-e, CT-e, MDF-e and the bookkeeping returns — EFD, ECD, ECF, eSocial, EFD-Reinf. One document model, every layout.
PIX and the instant-payment system, plus boleto — issued, reconciled and settled through the same integration as the documents.
Every contract derives from the authority's current layout. The API won't let you express a value the layout doesn't define — nor relax a rule it fixes.
Each authority's technical fields stay in dbr-gov's translation layer. Your integration speaks a clear, stable language.
What you actually get
The obligations and rails that used to need a vendor each, a project each — and a fire drill at every layout change — delivered as one calm, versioned surface.
Issue any document in the family from one model. A two-phase flow returns the document for review before anything is signed or sent.
Initiate PIX, issue boleto, settle instantly — the same integration, the same envelope, the same error model as the fiscal side.
The contract evolves additively, ahead of deadlines. A layout change becomes a version bump you schedule — not a migration that breaks you.
Every spec change carries its homologação and produção dates as first-class data — a countdown, not a surprise.
Documents reference the certificate by opaque handle; signing happens inside the host that owns the key. Your private keys never transit the API.
Build locally, inspect the exact document, then authorize. Nothing is signed or sent until you've seen precisely what the authority will.
The dominant challenge — and why it's our moat
what breaks naïvely
Layouts shift on government deadlines. Each authority has its own naming, signature ritual and schema. Miss a date and you stop being able to invoice. Most integrations hard-code one document, one version — and break on schedule, loudly, in production.
how dbr-gov solves it
One contract is the single source of truth; SDKs, REST and docs are generated from it. In-flight changes ship behind opt-in flags during homologation and promote at the production deadline — so deadline-driven change lands without breaking you. Compliance becomes infrastructure, not a fire drill.
API surface
Behind the shared dbr-core gateway — a uniform envelope and error model, whether you're emitting a document or moving money.
Part of a bigger machine
The same entities and places the platform resolves are the ones you invoice, screen and pay — so compliance and transactions inherit the platform's keys.
Join the list
One integration for every fiscal document and payment rail in Brazil — versioned, auditable, and ready for the Tax Reform. dbr-gov is in development; talk to the team to follow the roadmap.