Generating Brazilian receipt (recibo) PDFs

A recibo is not a small invoice — it is a different document with a narrative body, the amount in words and a signature line. Here is what it must say and how to produce one.

Updated 2026-08-07 · 7 min read · by the FaturaPDF team

A recibo evidences that money was received. It shows up constantly in Brazilian business: a freelancer confirming payment, a landlord confirming rent, a platform confirming a payout, a service provider confirming a deposit. It is a private document — no tax authority authorizes it — which is precisely why software can produce it.

What trips people up is assuming it is a stripped-down invoice. It is not; it reads differently and contains different things.

Invoice versus receipt

What a recibo should contain

There is no single legally mandated form, but the conventional content is stable and people notice when it is missing:

• The word "RECIBO" as a heading, and the amount prominently.
• Who received — name and CPF/CNPJ. This is the party issuing the document.
• Who paid — name and, ideally, CPF/CNPJ, because the payer usually needs it for their own records.
• The amount in figures and in words. Both. The convention comes from paper documents, where digits could be altered and words could not, and it survives because it makes a discrepancy obvious.
• What it refers to — "referente a serviços de consultoria prestados em julho/2026". A vague recibo is much less useful to the payer's accountant.
• Place and date.
• A signature line for the receiving party.

The canonical opening sentence is a fixed formula, and using it makes the document look right to a Brazilian reader:

Recebemos de COMERCIO SILVA & FILHOS ME, CNPJ 22.333.444/0001-81,
a importância de R$ 6.149,90 (seis mil, cento e quarenta e nove reais
e noventa centavos), referente a serviços de consultoria prestados
em julho de 2026.

São Paulo, 07/08/2026.

_______________________________________
ATLAS SOLUÇÕES DIGITAIS LTDA
CNPJ 11.222.333/0001-81

Generating one

The payload is the same as an invoice with tipo set to "recibo". The amount in words is added automatically — you do not opt in:

curl -X POST "https://brazilian-invoice-receipt-pdf-api-cpf-cnpj.p.rapidapi.com/receipt" \
  -H "Content-Type: application/json" \
  -H "X-RapidAPI-Key: $RAPIDAPI_KEY" \
  -H "X-RapidAPI-Host: brazilian-invoice-receipt-pdf-api-cpf-cnpj.p.rapidapi.com" \
  --output recibo.pdf \
  -d '{
    "numero": "REC-0042",
    "data": "2026-08-07",
    "emitente": {
      "nome": "Atlas Solucoes Digitais LTDA",
      "documento": "11.222.333/0001-81",
      "endereco": "Av. Paulista, 1000 - Sao Paulo/SP"
    },
    "destinatario": {
      "nome": "Comercio Silva & Filhos ME",
      "documento": "22.333.444/0001-81"
    },
    "itens": [
      { "descricao": "Servicos de consultoria - julho/2026", "valor_unitario": 6149.90 }
    ],
    "observacoes": "Pagamento recebido via PIX em 07/08/2026."
  }'

POST /receipt forces tipo="recibo"; POST /invoice with "tipo": "recibo" in the body is equivalent. Use whichever reads better in your code.

The amount in words

This is the part most home-grown receipt generators get subtly wrong, because Portuguese has rules that a naive number-to-words port does not encode:

R$ 100,00        cem reais                   (not "cem e zero")
R$ 101,00        cento e um reais            (not "cem e um")
R$ 1.000,00      mil reais                   (not "um mil reais")
R$ 1.000.000,00  um milhão DE reais          (the "de" is required)
R$ 1.500.000,00  um milhão e quinhentos mil reais   (no "de" - a remainder follows)
R$ 1,00          um real                     (singular)
R$ 0,05          zero reais e cinco centavos

Each of those is a rule: cem versus cento, no article before mil, the mandatory de after a million-or-higher scale word but not when a remainder follows, and singular real. The full implementation with all four rules is in the formatting guide. If you build it yourself, table-drive exactly the seven values above — they are where implementations break.

When to generate it

Tie it to a payment-confirmed event rather than to a user clicking a button, so the document always exists and always matches reality:

// Webhook from your payment provider
export async function onPaymentConfirmed(payment) {
  const pdf = await generateReceipt({
    tipo: "recibo",
    numero: `REC-${payment.id}`,
    data: payment.confirmedAt.toISOString().slice(0, 10),
    emitente: COMPANY,
    destinatario: {
      nome: payment.payer.name,
      documento: payment.payer.taxId,      // validated at signup, not here
    },
    itens: [{
      descricao: `${payment.description} - ${formatPeriod(payment.period)}`,
      valor_unitario: payment.amountCents / 100,
    }],
    observacoes: `Pagamento recebido via ${payment.method} em ${formatDateBR(payment.confirmedAt)}.`,
  });

  await storage.put(`receipts/${payment.id}.pdf`, pdf);
  await email.send(payment.payer.email, "Seu recibo", { attachments: [{ filename: "recibo.pdf", content: pdf }] });
}

Numbering

Receipts are not tax documents, so there is no mandated sequence — but sequential, gap-free numbering is what an accountant expects and what makes an audit conversation short. A per-year sequence (REC-2026-0001) is the common choice. Whatever you pick, make it unique and never reuse a number after a cancellation: issue a new one and mark the old as cancelled.

No API needed for one-offs

If you need a single receipt rather than an integration, the free browser generator produces the same layout entirely client-side — no signup, no API key, and nothing leaves your machine. It runs the same validation and layout logic as the API, bundled for the browser. The API is for when this needs to happen automatically, hundreds of times.

Frequently asked questions

Related guides