FaturaPDFBrazilian fiscal documents explained: NF-e, NFS-e, NFC-e, fatura, recibo, boleto
Foreign developers routinely translate all of these as "invoice" and then discover, late, that three different authorities are involved and only one of the documents can be produced by ordinary software.
If you are integrating billing for Brazil, the first useful thing to internalize is that "invoice" maps to at least three unrelated concepts in Portuguese, governed by three different levels of government, with three different technical realities.
Get this wrong and you build the wrong thing: teams routinely ship a beautiful "nota fiscal generator" that produces a PDF with no legal standing whatsoever, or conversely assume they need a full SEFAZ integration when their actual need was a payment receipt. If you already know you are in the services case, the NFS-e versus receipt decision guide is the shorter path.
This page explains how the documents differ from a software engineer's point of view, so you can model them correctly. It is not advice about your obligations. Brazilian tax rules vary by municipality, by activity code and by tax regime, and they are changing through the current reform. Before you decide what your company must issue, talk to a Brazilian accountant (contador).
The map
| Document | What it is | Authorized by | Can plain software produce it? |
|---|---|---|---|
| NF-e (model 55) | Electronic invoice for goods | State tax authority (SEFAZ) | No — needs a digital certificate and SEFAZ authorization |
| NFC-e (model 65) | Consumer retail sale (the old paper till receipt) | State (SEFAZ) | No — same requirement |
| NFS-e | Electronic invoice for services | Municipality (the city hall) | No — city system + certificate |
| CT-e / MDF-e | Freight transport document / cargo manifest | State (SEFAZ) | No |
| DANFE | The printout that represents an authorized NF-e | — | Yes, but only after an NF-e exists |
| Fatura | Commercial billing document — what you owe, itemized | Nobody. Private document. | Yes |
| Duplicata | Credit instrument derived from a fatura | Nobody (but legally regulated) | Yes |
| Recibo | Acknowledgement that a payment was received | Nobody. Private document. | Yes |
| Boleto | Bank payment slip with a scannable barcode | A bank / payment institution | Only through a bank or PSP |
| PIX QR | Instant payment code | Nobody for static codes | Yes (static); dynamic needs a PSP |
The column that matters is the last one. Everything marked "No" requires cryptographic identity that belongs to the issuing company — which is why no third-party API can offer to "issue your notas fiscais" unless you hand it your certificate.
Why NF-e cannot be generated by a PDF library
An NF-e is not a document that happens to be electronic. It is a signed XML file authorized in advance by the state tax authority. The flow:
- Your system builds an XML in the official schema (hundreds of fields: products, NCM tax codes, CFOP operation codes, ICMS/IPI/PIS/COFINS calculations, transport data).
- You sign it with an ICP-Brasil digital certificate tied to the issuing company's CNPJ — typically an e-CNPJ A1 (a password-protected file) or A3 (a hardware token).
- You transmit it to your state's SEFAZ web service.
- SEFAZ validates and returns an authorization protocol with a 44-digit access key. Until that comes back, no valid document exists.
- Only then do you print the DANFE — a standardized summary sheet carrying the access key as a barcode. The DANFE is evidence of the NF-e, not the NF-e itself.
- Cancellation and correction have their own protocols and deadlines. You cannot just delete it.
A PDF that looks like a DANFE but carries no authorized access key is not a nota fiscal. It is a picture of one. Issuing it to a customer as if it were valid is a real problem for your client, not a cosmetic one. If someone sells you an "NF-e API" that does not ask for your certificate, ask harder questions.
NFS-e: the municipal one
Services are taxed by ISS, a municipal tax — so the service invoice is issued by the city, not the state. Historically that meant roughly 5,500 municipalities each running their own portal, with its own schema, its own authentication and its own quirks. Integrating "NFS-e in Brazil" meant integrating a specific city.
A national NFS-e standard has been rolling out to unify this, with a shared national environment and a common layout, and adoption has been extended progressively across municipalities and taxpayer categories. The direction of travel is clear; the coverage on any given date is not something to guess at. Check the current status for the specific municipality you are integrating.
One artefact worth knowing: the RPS (Recibo Provisório de Serviços), a provisional receipt some systems issue when the municipal service is unavailable, converted into a proper NFS-e afterwards within a deadline. If you see "RPS" in a spec, that is what it is.
Fatura, duplicata, recibo: the commercial layer
These are the ones ordinary software can produce, because no authority authorizes them.
Fatura
A billing document: who is charging whom, for what, how much, due when. In Brazilian commercial law a fatura is associated with a sale and can give rise to a duplicata. In everyday software usage it is simply "the invoice we send the customer so they know what to pay". It does not replace a nota fiscal and does not, by itself, discharge any tax obligation.
Duplicata
A credit instrument issued against a fatura — it can be endorsed, discounted at a bank, and protested if unpaid. Relevant if you are building receivables or factoring software; irrelevant if you are just sending a bill.
Recibo
A simple acknowledgement: "I received R$ X from Y, on date Z, for W." Traditional layout is a narrative paragraph, the amount also written out in words, and a signature line. It is proof of payment, not of a taxable transaction. A recibo does not substitute for a nota fiscal when one is required — a distinction with real consequences for the payer, who may need the nota fiscal to deduct the expense.
Boleto and PIX: payment, not documentation
A boleto bancário is a bank instrument. The barcode and the "linha digitável" encode the bank, the amount, the due date and a check structure; the bank reconciles payment back to you. You cannot legitimately generate one without a bank or payment institution behind it, because the identifiers belong to them.
PIX is different: a static QR code is a self-contained string you can build yourself, since it only encodes your own key and the amount — see the BR Code format guide. Dynamic PIX codes, which support per-charge reconciliation, do require PSP integration.
Neither is a fiscal document. A paid boleto proves payment; it says nothing about whether a nota fiscal was issued.
A decision table for engineers
| Your situation | What you probably need |
|---|---|
| Brazilian company selling physical goods | NF-e, via a certificate-holding integration. Plus a fatura/boleto for the commercial side. |
| Brazilian company selling services | NFS-e in the relevant municipality. A fatura for billing. |
| Foreign company billing a Brazilian customer | You are generally outside the Brazilian issuance system — a commercial invoice is the norm. Your customer's obligations may still exist. Ask their accountant. |
| Marketplace paying Brazilian sellers | A recibo/payout statement for the payment; the seller issues their own nota fiscal. See marketplace payouts. |
| SaaS that needs "send my user a professional invoice PDF" | A fatura. This is the commercial-layer case an API covers well. |
| You need proof a payment happened | A recibo. |
| You need the customer to be able to deduct the expense | A nota fiscal (NF-e or NFS-e). No PDF generator substitutes for this. |
The reform on the horizon
Brazil is in the middle of a consumption-tax reform that replaces several existing taxes with a dual VAT (CBS at federal level and IBS at state/municipal level), phased in over several years with a transition period in which old and new coexist. For software this means document layouts, XML schemas and required fields are moving targets during the transition.
Practical engineering advice, independent of the details: do not hard-code tax fields into your document layer. Keep the presentation (a PDF a human reads) decoupled from the fiscal record (an authorized XML), so a schema change touches one side only. That separation is worth having regardless of the reform.
Where a document-generation API fits
Honestly and narrowly: in the commercial layer.
- Good fit: a fatura your customer reads and pays; a recibo confirming payment; a payout statement for a seller or freelancer; a proforma or quote; anything where the requirement is "a clean, correctly formatted Brazilian document" rather than "a legally authorized tax record".
- Wrong tool: anything where the deliverable must carry a SEFAZ or municipal authorization key. For that you need a fiscal integration with your certificate, and there are established Brazilian providers who do exactly that.
The two often coexist in the same product: the fiscal integration produces the nota fiscal, and a document API produces the human-facing fatura or receipt that accompanies it.
Frequently asked questions
What is the difference between NF-e and NFS-e?
NF-e covers goods and is authorized by the state tax authority (SEFAZ); NFS-e covers services and is authorized by the municipality, because the service tax (ISS) is municipal. They have different schemas, different systems and different rules. Both require a digital certificate tied to the issuer's CNPJ.
Can an API issue a nota fiscal for me?
Only if you give it your ICP-Brasil digital certificate, because the document must be cryptographically signed by the issuing company and authorized by a tax authority. Any API that produces a 'nota fiscal' without touching your certificate is producing a PDF that looks like one — which is not the same thing and should not be sent to customers as if it were.
Is a recibo enough, or do I need a nota fiscal?
They answer different questions. A recibo evidences that a payment was received; a nota fiscal documents a taxable transaction. When a nota fiscal is required, a recibo does not replace it — and your customer may be unable to deduct the expense without one. Whether it is required in your case depends on your activity and tax regime: ask an accountant.
What is a DANFE?
The printed representation of an authorized NF-e — a standardized one-page summary carrying the 44-digit access key as a barcode. It is evidence that an NF-e exists in SEFAZ's records; it is not itself the fiscal document, and printing a DANFE-shaped PDF without an authorized NF-e behind it means nothing.
I am a foreign company billing customers in Brazil. What do I issue?
Generally a commercial invoice, since the Brazilian issuance systems are built around Brazilian-registered entities. Your Brazilian customer may still have obligations around the transaction (withholding, import of services), which is their accountant's territory, not something a document generator can settle.
Need the formatted document, not the tax filing?
FaturaPDF generates the commercial layer — fatura and recibo PDFs with validated CPF/CNPJ, BRL formatting and optional PIX QR. It does not issue NF-e or NFS-e, and this page explains exactly why no API can do that on your behalf without your digital certificate.
Get an API key on RapidAPI → Or try the free browser generator