Por que a conferência entre pedido de compra e fatura no Japão falha com mais frequência
do que a maioria das equipes de compras prevê no orçamento

Três Documentos, Uma Transação — E Nenhum Modelo de Dados Compartilhado

A conferência tripla (三点照合, santen totsugō) é a salvaguarda universal de compras: verificar se o que você pediu, o que o fornecedor entregou e o que ele faturou descrevem a mesma transação antes de liberar o pagamento. A Lei de Subcontratação da Comissão de Comércio Justo do Japão (下請代金支払遅延等防止法), reforçada pela Lei de Transações Justas para PMEs de 2026 (中小受託取引適正化法, informalmente 取適法), determina que todo pedido de compra emitido para um subcontratado contenha campos específicos — local de entrega (納入場所, nōnyū basho), condições de pagamento com data de fechamento (支払条件・締日, shiharai jōken / shimebi), data de conclusão da inspeção — tornando o pedido de compra a âncora legal da transação. Na teoria, o fluxo de conferência é linear: pedido de compra → entrega → fatura → pagamento. Na prática, é uma colisão tripla de formatos, prazos e convenções de nomenclatura.

O problema central não é que a conferência seja tediosa. É que cada um dos três documentos foi gerado por um sistema diferente, em um momento diferente, para um público diferente, e nenhum deles usa os mesmos identificadores. Um gerente de compras cria um pedido de compra no ERP da empresa — digamos, OBIC7 ou SAP Japan — com campos estruturados vinculados ao cadastro interno de fornecedores. O fornecedor envia a mercadoria com uma nota de entrega em papel que usa os códigos de produto próprios e escreve as quantidades à mão. Duas semanas depois, o departamento de faturamento do fornecedor emite uma fatura — geralmente de outro sistema, possivelmente um serviço em nuvem como freee ou MoneyForward — com descrições de linha que não correspondem textualmente nem ao pedido de compra nem à nota de entrega. Três documentos. Uma transação. Três representações de dados incompatíveis.

A Associação de CFOs do Japão relatou que aproximadamente 30% do tempo de trabalho do departamento de contabilidade é gasto em tarefas de verificação e conferência de documentos. Em uma equipe de compras que processa 200 pedidos de fornecedores por mês, isso se traduz em cerca de 60 horas mensais — uma semana e meia de trabalho integral — gastas não na negociação de melhores condições ou na gestão de relacionamentos com fornecedores, mas no ato mecânico de confirmar que três números em três pedaços de papel afirmam descrever a mesma coisa.

Onde a Correspondência Realmente Falha — Os Quatro Modos de Falha

A conferência tripla não é uma única verificação. É uma sequência de comparações distintas, e cada uma pode falhar de forma independente por motivos que nada têm a ver com erro humano. Entender o porquê é a diferença entre tratar o sintoma e tratar a estrutura.

1. Divergência de Quantidade: A Entrega que Não Corresponde ao Pedido

Um fornecedor confirma um pedido de compra de 200 unidades de parafusos sextavados M10. Eles enviam 140 unidades na primeira entrega e 60 unidades duas semanas depois. A primeira nota de entrega indica 140. A segunda indica 60. A fatura — emitida após a segunda entrega — indica 200. A equipe de contas a pagar, trabalhando com a fatura, vê 200 unidades e as compara com o pedido de compra de 200. A correspondência parece correta. Mas 80 dessas unidades chegaram após o prazo do projeto, ficaram sem uso e deveriam ter sido negociadas como um ajuste de preço.

分納 (entrega parcial, bunnō) é a fonte mais comum de erros de correspondência em compras no Japão, e se agrava quando as notas de entrega chegam em papel dentro da caixa de transporte — rastreadas pelo almoxarifado, não pela contabilidade. Quando a fatura chega ao setor de contas a pagar, as notas de entrega dos dois embarques podem estar em duas pilhas de arquivamento separadas, digitalizadas em resoluções diferentes ou simplesmente perdidas. A correspondência falha não porque os dados estão errados, mas porque os dados estão fragmentados em dois documentos físicos que nenhum sistema conecta.

2. Mudanças na Alíquota do Imposto sobre Consumo — Quando a Alíquota na Fatura Difere da Alíquota no Pedido de Compra

O imposto sobre consumo do Japão (消費税, shōhizei) está em 10% (alíquota padrão) e 8% (alíquota reduzida para alimentos e bebidas) — um sistema de duas faixas vigente desde o aumento de outubro de 2019. A alíquota aplicável é determinada pela data de entrega, não pela data do pedido de compra. Se um pedido de compra for emitido em setembro com a alíquota de 8%, mas as mercadorias forem entregues em outubro, quando a alíquota passou a ser de 10%, a fatura deve legalmente refletir a alíquota de 10%. O pedido de compra ainda indica 8%. Os dois documentos nunca corresponderão no total — e a diferença não é um erro, é a lei tributária.

Mesmo fora de eventos de mudança de alíquota, o simples fato de que diferentes itens de linha podem estar sujeitos a alíquotas de imposto diferentes — um carregamento misto de materiais de escritório (10%) e alimentos embalados (8%) — significa que o total da fatura não pode ser mecanicamente comparado ao total do pedido de compra sem decompor ambos os documentos linha por linha. Equipes manuais de contas a pagar frequentemente pulam essa decomposição e verificam apenas os totais, o que significa que classificações incorretas do imposto sobre consumo passam despercebidas até que uma auditoria fiscal as detecte.

3. Condições de Pagamento Divergentes entre Pedido de Compra e Fatura

As condições de pagamento B2B japonesas seguem uma convenção que é simultaneamente precisa e fácil de interpretar erroneamente: o dia de fechamento (締日, shimebi) emparelhado com uma janela de pagamento. Um termo típico é 20日締め翌月末払い — "transações até o dia 20 do mês, pagas até o final do mês seguinte." O pedido de compra declara este termo explicitamente, conforme exigido pela Lei de Subcontratação. Mas o sistema de faturamento do fornecedor pode usar como padrão 10日締め翌々月末払い — um corte diferente e uma janela de pagamento diferente. Se a fatura do fornecedor indicar uma data de vencimento que não esteja alinhada com os termos do pedido de compra, a fatura é tecnicamente não conforme, e pagá-la nos termos declarados pelo fornecedor pode significar liberar caixa um mês inteiro antes do contratualmente exigido.

A verificação de correspondência para condições de pagamento exige que a contas a pagar leia um campo de texto curto em dois documentos diferentes e os compare — uma tarefa que não pode ser automatizada com PROCV porque os termos não são um número. Na prática, a maioria dos fluxos de trabalho de correspondência manual pula essa verificação completamente, focando em quantidades e totais. Pular a verificação das condições de pagamento custa a um fabricante de médio porte cerca de 2-3% do contas a pagar mensal em saída de caixa precoce evitável, de acordo com consultores de compras que trabalham com PMEs japonesas — dinheiro que fica na conta do fornecedor em vez da do comprador por um mês inteiro, multiplicado em cada transação.

4. O Documento Ausente — Quando Um dos Três Não Existe

Nem toda transação de fornecedor gera uma trilha limpa de três documentos. Pedidos por telefone, mensagens no LINE para fornecedores antigos, compras urgentes aprovadas verbalmente por um chefe de departamento — estas criam transações onde o pedido de compra existe apenas na memória de alguém. Em empresas japonesas menores, a cultura do 発注書 é mais aspiracional do que operacional: uma pesquisa de 2023 da Agência de Pequenas e Médias Empresas (中小企業庁) descobriu que mais de 40% das transações de PMEs abaixo de ¥100.000 foram feitas sem um pedido de compra formal. O processo de correspondência para essas transações começa com uma nota de entrega que não referencia nenhum número de pedido de compra e uma fatura que pode ou não referenciar uma data de pedido.

Quando um documento está faltando, as equipes de contas a pagar enfrentam uma escolha binária: atrasar o pagamento enquanto reconstroem a trilha de papel, ou aprovar com base em uma correspondência de 2 vias (fatura contra nota de entrega, ou fatura contra pedido de compra sozinho) e aceitar o risco. A maioria escolhe a última opção — não por negligência, mas porque a alternativa significa reter pagamentos a fornecedores cujas mercadorias já estão na linha de produção. O resultado é que a estrutura de controle interno da empresa — o próprio propósito da conferência tripla — só se aplica ao subconjunto de transações onde todos os três documentos existem por acaso.

A Armadilha da Planilha — Por Que o Excel Torna o Problema Mais Silencioso, Não Menor

A resposta padrão ao caos da conciliação é a planilha. Exporte os dados do pedido de compra do ERP. Digite manualmente os dados da nota de entrega em uma segunda planilha. Importe os dados da fatura do PDF do fornecedor. Escreva um PROCV no número do pedido. Sinalize as divergências. Aprove as correspondências. Siga em frente.

Esse fluxo de trabalho funciona — no sentido de que eventualmente produz uma lista de transações a pagar. Ele falha no sentido de que a planilha absorve a complexidade sem resolvê-la. O PROCV no número do pedido só funciona se o número do pedido aparecer de forma idêntica nos três documentos. Na prática, o campo do número do pedido é o identificador mais confiável — e ainda assim falha quando o sistema de faturamento do fornecedor trunca o número do pedido, adiciona um prefixo de código de departamento, ou quando a nota de entrega simplesmente não o inclui porque o armazém imprimiu um romaneio de um sistema diferente.

Mas o número do pedido é o campo fácil. A verdadeira armadilha da planilha é a conciliação item a item. Um parafuso descrito no pedido de compra como "SUS304 M8×30 六角ボルト" aparece na nota de entrega como "ステンレスボルト M8×30" e na fatura como "部品コード BT-0842 六角穴付ボルト M8 L=30." Os três descrevem o mesmo item físico. Nenhum deles corresponde como texto. O PROCV retorna #N/D e o funcionário de contas a pagar abre três documentos para confirmar visualmente que estes são, de fato, o mesmo parafuso — o que leva 90 segundos por item de linha, e há 400 itens de linha nas faturas do mês.

A planilha não falha. Ela faz a equipe acreditar que a conciliação está completa — quando, na verdade, cada #N/D esconde uma divergência real que precisa de investigação ou uma falsa divergência causada por inconsistência de nomenclatura. Com o tempo, a equipe se adapta reduzindo seus padrões de conciliação: conciliar por número do pedido e valor total, pular a verificação item a item, sinalizar apenas grandes divergências. Essa adaptação é racional — a alternativa é uma fila infinita de faturas não processadas — mas significa que a conferência tripla foi rebaixada para uma conferência de 1,5 via na prática, e a ACFE estima que as organizações perdem aproximadamente 5% da receita anual para fraudes, grande parte das quais passa por controles fracos de faturamento.

Para um passo a passo mais detalhado de como obter dados de pedidos de compra em uma planilha, consulte nosso guia sobre extração de dados de pedidos de compra japoneses para Excel — o artigo central que aborda a estrutura campo a campo de um 発注書 e como converter cada um em uma linha estruturada. Para a contrapartida de processamento em lote, processamento em lote de pedidos de compra de cinquenta fornecedores em um único painel de compras aborda a dimensão de escala que transforma a conciliação de uma tarefa mensal em um gargalo estrutural. E para o fluxo de trabalho completo de conciliação no Excel depois que os dados estão em uma planilha — junções XLOOKUP e rastreamento de entregas parciais — consulte nosso guia para conciliar faturas de fornecedores com pedidos de compra na manufatura.

Por que a Extração Semântica Muda a Equação da Conciliação

A abordagem de planilha pressupõe que os dados já estão estruturados — que "Número do Pedido", "Nome do Item" e "Preço Unitário" existem como campos limpos em um banco de dados. O ponto de partida real são três PDFs, possivelmente um scan de uma nota de entrega em papel, cada um com seu próprio layout e vocabulário. Antes que qualquer conciliação possa acontecer, alguém precisa converter esses PDFs em linhas e colunas. Essa etapa de conversão é onde o gargalo realmente reside.

As ferramentas tradicionais de OCR tentam essa conversão identificando a posição de cada campo na página — "o número do pedido está a 3cm do topo, 4cm da esquerda" — usando modelos zonais que precisam ser definidos por formato de fornecedor ou parsers baseados em regras que quebram quando o layout muda. Essa abordagem falha no problema da conciliação por um motivo estrutural: os três documentos têm layouts completamente diferentes. O número do pedido fica no cabeçalho do PDF do pedido, pode não aparecer na nota de entrega e vive em um campo de número de referência na fatura. Uma regra de extração baseada em posição escrita para o layout do pedido é inútil contra o layout da fatura.

Extração semântica — a abordagem que o Custom Column Extraction permite — inverte a lógica. Em vez de definir onde cada campo está em cada documento, você define o que deseja: uma coluna chamada "Número do Pedido", uma coluna chamada "Nome do Item", uma coluna chamada "Quantidade". A IA lê cada documento e localiza os valores entendendo o que eles significam, independentemente de onde aparecem na página ou como são rotulados. Um pedido de compra enviado por fax com o número do pedido em um cabeçalho emoldurado e uma fatura em PDF onde o mesmo número aparece em um campo "ご注文番号" ambos retornam a mesma coluna — porque a IA está fazendo a correspondência por semântica, não por coordenadas.

Isso muda o fluxo de trabalho de conciliação de "converter três documentos em três planilhas diferentes, depois reconciliar" para "extrair os três documentos para a mesma estrutura de colunas, depois comparar". A etapa de comparação se torna uma operação de planilha de verdade — uma busca na coluna Número do Pedido que realmente retorna uma correspondência porque a coluna foi preenchida por uma IA que entendeu o que cada documento significava, não por um humano transcrevendo o que cada documento dizia.

Esse mesmo problema estrutural — conciliação manual entre documentos que descrevem a mesma realidade financeira, mas em formatos incompatíveis — aparece em outros contextos além do Japão. Nossa análise do problema de conciliação manual no envio do BAS australiano examina como pequenas empresas enfrentam um desafio análogo quando os dados trimestrais de GST precisam ser conciliados entre extratos bancários, faturas e formulários da ATO, cada um com seu próprio formato e esquema de identificadores. É também o mesmo motivo por trás da taxa de falha na conferência tripla no AP da manufatura global — veja por que a conferência tripla prejudica o AP da manufatura mais do que as equipes admitem.

Perguntas Frequentes

O que é a conferência tripla e por que ela é exigida na aquisição japonesa?

A conferência tripla (三点照合) cruza um pedido de compra (発注書, hatchūsho), uma nota de entrega (納品書, nōhinsho) e uma fatura (請求書, seikyūsho) para confirmar que o que foi pedido, entregue e faturado descreve a mesma transação. A Lei de Subcontratação (下請代金支払遅延等防止法) da JFTC exige campos específicos em todo pedido de compra emitido para subcontratados, e o processo de conferência é um controle interno essencial para evitar pagamento em excesso, pagamento duplicado e pagamento por mercadorias não entregues.

Por que a conferência entre pedido de compra e fatura falha mesmo quando os dados estão corretos?

Os documentos usam identificadores diferentes para os mesmos itens. Um único parafuso de aço inoxidável pode aparecer como "SUS304 M8×30" no pedido de compra, "ステンレスボルト M8" na nota de entrega e "BT-0842" na fatura. Os dados estão corretos — todos descrevem o mesmo item físico —, mas ferramentas de correspondência baseadas em texto, como VLOOKUP, retornam incompatibilidades porque as strings são diferentes. Entregas parciais (分納), diferenças de alíquota de imposto (消費税) e desalinhamento nas condições de pagamento agravam esse problema.

É possível automatizar a conferência tripla sem alterar os formatos de documento dos meus fornecedores?

Sim — o segredo é extrair dados semanticamente, e não por posição. Quando o mecanismo de extração lê "obtenha o número do pedido" e "obtenha o nome do item" como definições de coluna, ele busca em cada documento valores que respondam a essas perguntas, independentemente do layout ou da rotulagem. Seus fornecedores continuam usando os formatos existentes — a etapa de extração normaliza a saída em uma estrutura de coluna consistente, e a conferência ocorre com base nesses dados normalizados.

O que acontece se um dos três documentos estiver faltando?

Esse é o cenário mais comum na prática. Pedidos por telefone, mensagens no LINE e aprovações verbais criam transações sem um pedido de compra formal. Quando um documento está faltando, muitas equipes de contas a pagar recorrem a uma conferência dupla (fatura contra nota de entrega, ou fatura contra pedido de compra) — que é mais rápida, mas remove uma camada de verificação. A melhor mitigação é tornar a criação de documentos o mais simples possível: se o gerente de aquisição puder digitalizar uma nota de pedido manuscrita e extraí-la no mesmo formato estruturado de um pedido de compra formal, a trilha documental existirá mesmo quando o processo formal não ocorreu.

O imposto sobre consumo (消費税) é o único problema de correspondência relacionado a impostos?

O imposto sobre consumo é a fonte mais comum de divergência relacionada a impostos, porque o sistema de alíquotas duplas (10% padrão, 8% reduzido para alimentos) significa que uma única fatura pode conter itens com alíquotas diferentes. Mas não é o único. Transações que envolvem mercadorias importadas geram direitos aduaneiros (関税) que aparecem nos documentos de embarque, mas não no pedido de compra. Transações transfronteiriças dentro da cadeia de suprimentos global de uma empresa japonesa podem envolver ajustes de preços de transferência que afetam o total da fatura sem qualquer linha correspondente no pedido de compra original.

Como isso difere do que os sistemas ERP empresariais já tratam?

ERPs empresariais como SAP Japan ou OBIC7 fornecem módulos de conferência tripla, mas exigem que os dados estejam no sistema antes que a correspondência possa ocorrer. A lacuna é a etapa de entrada de dados: um mecanismo de correspondência do SAP não consegue corresponder a uma fatura armazenada como PDF na sua caixa de entrada de e-mail. Os ERPs automatizam a comparação — eles não automatizam a extração de documentos não estruturados. Para empresas que já possuem um ERP, o gargalo está a montante do módulo de correspondência: inserir os dados da nota de entrega e da fatura no ERP em primeiro lugar.