5 Boleto Data Entry Mistakes
That Trigger Protesto — and How to Avoid Them

What Is Protesto, and How Does a Data Entry Error Trigger It?

Protesto is the formal registration of an unpaid debt with a Cartório de Protesto (notary office). It is the first legal step in Brazilian debt enforcement — before a lawsuit can be filed, the creditor must typically have the debt protested to establish the public record of non-payment. The process works like this:

1. The creditor presents the unpaid Boleto to the cartório.
2. The cartório notifies the debtor, who has three business days to pay or contest the debt.
3. If the debtor does not respond, the protesto is registered and becomes a public record accessible to credit bureaus (Serasa and SPC).
4. The protested debt stays on the debtor's credit history until it is paid and the protesto is canceled at the cartório.

The critical detail for the AR team: protesto is triggered when the system believes a Boleto is unpaid past its due date. If the data entered for that Boleto is wrong — the barcode was mis-keyed, the due date was entered incorrectly, or the payment was applied to the wrong Boleto because of a duplicated Nosso Número — the system may flag it as unpaid when it actually was settled. The protesto process does not check for data entry errors. It only checks whether the record in the system shows an outstanding balance.

Mistake 1: Transposing the Código de Barras (Barcode)

The 44-digit barcode is the unique identifier for each Boleto. It is also, at 44 digits, the field most prone to manual entry errors. A single transposition — typing digit 19 where digit 20 should be, or swapping "1234" for "1243" — creates a barcode that either fails validation checksum validation (mod 10 or mod 11, depending on the bank) or, worse, passes validation but resolves to a different Boleto.

The consequence of the first type (failing validation) is immediate: the system rejects the barcode, the analyst notices, and they correct it. The consequence of the second type (passes validation but wrong Boleto) is much more dangerous: the payment is recorded against the wrong Boleto, leaving the correct Boleto unpaid in the system. When the issuer runs their aging report at month-end, the correct Boleto shows as overdue. If that report triggers the protesto workflow — which is automated in many Brazilian ERPs — the wrong Boleto is sent to protesto.

The only reliable prevention is to eliminate the manual transcription step entirely. When the barcode is read directly from the PDF by an extraction tool, the transposition error category disappears — the tool reads all 44 digits in the correct order and writes them to the output without human keystrokes between the source document and the spreadsheet row.

Mistake 2: Misreading the Vencimento (Due Date)

The due date (data de vencimento) is printed on every Boleto in DD/MM/YYYY format — this is the Brazilian standard. But an AR analyst trained in another region, or working in a system configured for MM/DD/YYYY, can easily misread "05/12/2026" as May 12th instead of December 5th. In the other direction, a Brazilian analyst reading an international system's output may misinterpret the date format the other way.

A wrong due date has two protesto-related consequences:

• The Boleto appears to be past due before it actually is. If the due date was entered as "05/12" instead of "12/05," the system starts counting overdue days two months earlier. By the time the real due date arrives, the system has already flagged the Boleto for escalation.
• The late payment interest (juros de mora) and penalty (multa) are calculated on the wrong date base. Brazilian law allows up to 1% monthly interest on late payments plus a ~2% multa. If the system thinks the Boleto was due in May but it was actually due in December, it may apply six extra months of interest — creating a dispute when the payer contests the amount.

In automated ERPs like Totvs (Protheus) or SAP, the due date field in the system directly controls the aging bucket assignment. If the date is wrong, the bucket assignment is wrong, and the protesto trigger logic has no way to know it received bad input.

Mistake 3: Duplicating or Misentering the Nosso Número

The Nosso Número (Our Number) is the bank's internal reference for each Boleto. Unlike the 44-digit barcode, which is standardized across all banks, the Nosso Número format varies by bank — Bradesco uses one length, Itaú uses another, and Santander uses a third. Some banks include check digits; others do not.

When an AR team manually enters the Nosso Número from the Boleto PDF into the tracking spreadsheet, two things go wrong with disproportionate frequency:

• Duplication: The analyst enters "12345678" for one Boleto and "12345687" for another — the digits are nearly identical, and the spreadsheet does not flag the similarity. Later, when the bank settlement report arrives with payment for Nosso Número "12345678," the system matches it to the first Boleto (correctly) but the second Boleto remains unpaid in the system even though its payment was identical (same bank, same date, similar amount).
• Truncation or padding: The analyst omits the leading zeros from a Nosso Número that the bank formats as "00012345678," entering "12345678" instead. When the bank's settlement report lists "00012345678," the match fails — the system sees two different strings.

Both scenarios create a phantom overdue Boleto — one that looks unpaid in the AR system but was actually settled. The longer the phantom persists (because the discrepancy is hard to spot when the amounts match), the more likely it is to enter the protesto pipeline.

Mistake 4: Recording the Wrong Valor (Amount)

Amount entry errors are the most detectable during reconciliation (the settled amount usually differs from the recorded amount), but they are also the most common — and in specific cases, they can trigger protesto indirectly.

Brazil uses the decimal comma: R$ 1.234,56 means one thousand, two hundred and thirty-four reais and fifty-six centavos. An analyst expecting the international convention may type "1234.56" into a system that expects "1.234,56" — or vice versa. The system either rejects the value (easily caught) or silently accepts it with the decimal shifted (dangerous). A Boleto of R$ 1.500,00 (one thousand five hundred) entered as "1500.00" in a system that reads the dot as a thousands separator may interpret it as R$ 1,50 (one real and fifty centavos) — a difference of 1,498,50 reais.

How this triggers protesto: If the amount recorded is less than the actual Boleto value, the system shows a partial balance remaining after payment. "Boleto issued for R$ 1.500,00. Payment received: R$ 1,50. Outstanding: R$ 1.498,50." The system generates a balance due notification. If unpaid, it escalates to protesto for the "remaining balance" — which is actually a decimal format error. The payer who already paid R$ 1.500,00 (the full amount) is now being protested for a phantom debt caused by a misplaced comma.

Mistake 5: Overlooking Partial Payments and Late Fees

This is less a single typing error and more a workflow failure, but it is the most common protesto trigger in practice. A payer sends R$ 500 of a R$ 1.000 Boleto — perhaps because they are disputing part of the invoice, perhaps because they only had R$ 500 at the time. The AR team records R$ 500. But the system still shows R$ 500 outstanding. The Boleto's due date passes. No further payment arrives. The system escalates to protesto for R$ 500.

The payer's view: "I paid R$ 500. Why am I being protested for R$ 500?" The issuer's view: "Only partial payment was received. The remaining balance is legitimate." Neither view is wrong — but the escalation to protesto for a disputed or acknowledged partial balance creates precisely the kind of customer friction that costs relationships, not just money.

Similarly, when a Boleto is paid after the due date, the actual amount received includes the original value plus late payment interest (juros de mora) and penalty (multa). If the AR system only tracks the original valor nominal, the settlement amount will exceed the recorded amount. The analyst sees a positive discrepancy — "overpayment" — and may treat it as unallocated cash rather than recognizing it as legitimate late payment charges. If that cash is not applied to the Boleto record, the system still shows an outstanding balance, and the protesto trigger may fire despite the payment having been settled in full (with interest).

How Extraction Automation Prevents These Errors Before They Happen

All five mistakes share a common root: a human keystroke stands between the Boleto PDF and the AR system. When the data is typed, errors can be introduced. When the data is extracted automatically, the errors in the list above are structurally prevented — not because the AI is "more accurate" than a human (though it typically is), but because the extraction pathway has no transcription step where the barcode digits or amount value pass through human fingers.

For the partial payment scenario specifically, automation helps by making the data available faster. When an AR team gets structured data from every Boleto in a batch within minutes, they can identify partial payments and adjust the tracking record before the system's automatic protesto trigger fires. The bottleneck in the manual workflow is not the knowledge of what to do — it is the time it takes to get the data into the system where the knowledge can be applied.

For a full step-by-step walkthrough of setting up an automated Boleto extraction workflow, see how to extract Boleto Bancário data to Excel.

Frequently Asked Questions

Every Typing Error Is a Potential Protesto Trigger

The five mistakes described here share a pattern: each one converts a correct payment into a false overdue record. The AR system does not know that the barcode was transposed or the due date was misread. It only knows that the data in its fields shows an outstanding balance past the due date. When that condition is met, the protesto trigger fires — and a customer who actually paid on time discovers they have a public debt record.

The solution is not to ask the AR team to type more carefully. The solution is to remove the typing step from the workflow entirely. The Boleto's data is already on the document, structured by a national standard. An extraction tool that reads it directly eliminates the five error vectors at their source — before they reach the spreadsheet, before they reach the ERP, and before they reach the cartório.