Skip to main content
Venda a prazo B2B tem um dado que pagamentos não representa: o parcelamento em duplicatas, com data de vencimento, que o financeiro do seu cliente concilia depois. É o bloco cobranca na raiz do payload da NF-e. pagamentos continua sendo a forma de pagamento efetiva (ex.: "15" boleto) e segue fechando o total transmitido. cobranca é informativo e financeiro: não altera vNF nem o que pagamentos já faz. O motor é passthrough aqui, nada é calculado.
  • Só NF-e (modelo 55): NFC-e documenta venda com pagamento imediato ao consumidor final e recusa o bloco com 422, mas só quando ele tem conteúdo de verdade ({} vazio passa batido, útil pra quem usa o mesmo payload nos dois modelos).
  • Duplicata não exige fatura: no leiaute, fatura e duplicatas são independentes. Você pode informar só as duplicatas.
  • Fatura é tudo ou nada: se você envia fatura, os 4 campos (numero, valorOriginal, valorDesconto, valorLiquido) são obrigatórios juntos, e valorLiquido precisa ser exatamente valorOriginal − valorDesconto.
  • Vencimento é obrigatório e auditado: precisa ser uma data real (não só o formato), maior ou igual a hoje, e as parcelas precisam vir em ordem não-decrescente de vencimento.
  • Coerência auditada: quando há fatura E duplicatas, a soma de duplicatas[].valor precisa bater com o líquido da fatura.

Pré-requisitos

Emitindo com fatura e duplicatas

O que sai no XML

O grupo vira <cobr> dentro de infNFe, entre <transp> e <pag> (estrutura validada contra o XSD oficial da NF-e 4.00):
Recupere o XML autorizado com GET /v1/nfe/xml/{accessKey}: ele é o artefato real que a SEFAZ recebeu, nunca uma remontagem.
duplicatas[].numero é opcional no payload, mas nunca fica de fora do documento. Se você não numerar as parcelas, a engineAPI preenche sequencial (001, 002…): o motor de emissão usa esse número como identificador interno da parcela, então ele nunca pode faltar no XML.

Campos do bloco cobranca

fatura e duplicatas são independentes: você pode enviar só duplicatas (parcelamento sem número de fatura formal) ou só fatura (sem detalhar as parcelas). No leiaute, dup não é filho de fat, os dois vivem direto sob cobranca.
A soma das duplicatas precisa bater com o líquido da fatura, quando os dois são informados. A comparação usa o valor como vai no documento (2 casas decimais) e é uma igualdade EXATA sobre esse valor, não uma tolerância. Divergência em qualquer direção (soma maior OU menor) devolve 422 COBRANCA_INVALIDA antes da numeração, citando os dois valores.
Vencimento fora de ordem entre as parcelas recusa. As duplicatas precisam vir em ordem não-decrescente de vencimento (a 2ª parcela não pode vencer antes da 1ª). Um vencimento anterior à data de emissão também recusa: a engineAPI não emite nota com parcela “vencida antes de nascer”.

Erros comuns

Todos os 422 acima são locais: acontecem antes de qualquer chamada à SEFAZ e antes da numeração, então nada é emitido e nenhum número fiscal é consumido. Em lote (POST /v1/nfe/batch) o item falha no pré-voo e sai FAILED com o mesmo code, sem retry.

Referências

  • MOC (Manual de Orientação do Contribuinte) Anexo I, grupo Y (cobr/ fat/dup): regras de negócio da fatura (Y04/Y05/Y06), do número da duplicata (Y07/Y08), do vencimento (Y09) e da soma das duplicatas contra a fatura (Y10).
  • Leiaute NF-e 4.00, elemento cobr dentro de infNFe (irmão de transp e pag).
  • Catálogo de erros: todos os code de negócio da API.
  • Emitir NF-e: o payload completo, campo a campo.
  • Campos de NFe: referência de todo campo aceito.