Por que a linha digitável do boleto usa mod10 e mod11 no mesmo número?

É uma decisão de design do padrão Febraban: mod10 protege cada campo individualmente (detecta erro de digitação campo a campo, sem precisar da linha inteira), enquanto o mod11 geral protege a integridade da linha como um todo, incluindo banco, valor e fator de vencimento. São duas camadas de proteção com propósitos diferentes, não uma redundância.

O dígito verificador geral do boleto pode ser 0?

Não, por convenção Febraban. Se o cálculo de mod11 resultar em dígito 0, 10 ou 11, o valor é forçado para 1. Um validador que aceita '0' como dígito verificador geral válido está implementando a regra errada — esse valor nunca deveria aparecer numa linha digitável real.

É possível pagar um boleto gerado por esta ferramenta?

Não. Os dígitos verificadores (mod10 e mod11) são matematicamente corretos, mas o 'campo livre' — que cada banco usa internamente para identificar a cobrança real — é preenchido com dígitos aleatórios, sem vínculo com nenhum registro bancário de fato. A linha passa em validação de formato, mas não corresponde a uma cobrança registrada em nenhum banco.

Gerador de Linha Digitável de Boleto

Gere uma linha digitável de teste, com dígitos verificadores (mod10/mod11) matematicamente corretos.

Código do banco

Valor (R$)

Os dígitos verificadores seguem o padrão Febraban (mod10 nos campos 1-3, mod11 no dígito geral), mas o "campo livre" (uso interno de cada banco) é fictício — esta linha não corresponde a um boleto real registrado e não pode ser paga. Uso exclusivo para testar máscaras/validações de formulário.

Documentação técnica

Gerador de Linha Digitável de Boleto: dois algoritmos no mesmo número

A linha digitável de um boleto bancário brasileiro (padrão Febraban) é incomum entre os documentos deste site por combinar dois algoritmos de dígito verificador diferentes no mesmo número: mod10 nos três primeiros campos, e mod11 no dígito verificador geral. A linha completa tem 47 dígitos, organizados em cinco campos — três campos de 10 dígitos (cada um terminando em seu próprio dígito verificador mod10), um dígito verificador geral (mod11, posição 5), e um campo de fator de vencimento + valor (sem dígito verificador próprio).

Mod10: o mesmo princípio do Luhn, aplicado em blocos menores

Os campos 1, 2 e 3 da linha digitável usam mod10 — o mesmo algoritmo de duplicação de dígitos alternados já documentado na página do gerador de Cartão de Crédito (dobrar dígitos em posições alternadas, subtrair 9 quando o resultado passa de 9, somar tudo, e o dígito verificador é o que falta para chegar ao próximo múltiplo de 10). A diferença é de escopo: no cartão de crédito, o mod10 roda sobre o número inteiro de uma vez; no boleto, ele roda três vezes, uma para cada campo de 10 dígitos, produzindo três dígitos verificadores independentes — um erro de digitação em qualquer um dos três campos é detectável isoladamente, sem precisar conferir a linha inteira.

Mod11: o dígito verificador geral

O quinto campo da linha — o dígito verificador geral, que aparece isolado entre o terceiro campo e o campo de vencimento/valor — usa Módulo 11 com pesos cíclicos de 2 a 9, aplicados da direita para a esquerda sobre os 43 dígitos que formam a linha sem os dígitos verificadores dos campos 1-3. Esse dígito geral é calculado sobre uma concatenação diferente da que o usuário vê na linha final — banco, moeda, fator de vencimento, valor e campo livre, sem os DVs de campo — o que costuma ser a parte mais confundida por quem implementa esse algoritmo pela primeira vez. Uma particularidade do mod11 do boleto: se o dígito calculado for 0, 10 ou 11, ele é forçado para 1 por convenção Febraban — um caso especial que não aparece no mod11 de CPF ou CNPJ.

Uso em testes de sistemas financeiros

Sistemas de conciliação bancária, ERPs com módulo financeiro e gateways de pagamento que geram ou leem boletos precisam validar a linha digitável nas duas camadas (mod10 por campo, mod11 geral) antes de considerá-la processável. Testar essa camada de validação — sem registrar um boleto real em nenhum banco, o que exigiria integração com convênio bancário real — é o caso de uso direto desta ferramenta: uma linha com os dois algoritmos corretos, mas cujo "campo livre" (de uso interno de cada banco) é fictício, então nunca corresponde a uma cobrança real e não pode ser paga.