30 Faturas de Fornecedores, Uma
Planilha de Contas a Pagar Pronta para Pagamento

O que a Extração de Arquivo Único Deixa de Fora

O artigo central sobre extração de dados de faturas japonesas para Excel cobre toda a estrutura de campos — como capturar dados bancários, condições de pagamento, imposto sobre consumo e retenção na fonte de uma única 請求書. Mas um fluxo de trabalho de arquivo único resolve o problema de extração por documento. Ele não resolve o problema de lote para pagamento, que é um problema diferente com um conjunto diferente de saídas.

O funcionário de contas a pagar que processa trinta faturas manualmente segue uma sequência: abrir o PDF da fatura, localizar o bloco de dados bancários, digitar os quatro campos bancários na tela do internet banking, interpretar as condições de pagamento para determinar a data de vencimento, verificar a retenção na fonte, conferir a discriminação do imposto sobre consumo e confirmar o número de registro da fatura qualificada no cadastro do fornecedor. Essa sequência se repete trinta vezes. O ato de extração — ler os dados da fatura — e o ato de preparação do pagamento — montar esses dados em um formato pronto para transferência bancária — se fundem em uma única tarefa repetitiva. Uma ferramenta de extração de arquivo único os separa: os dados são extraídos para uma linha de planilha. Mas a preparação do pagamento — montar essas trinta linhas em um arquivo de lote de pagamento, um calendário de pagamentos, um cronograma de depósito de retenção e um resumo do imposto sobre consumo pronto para declaração — ainda exige montagem manual. A extração resolveu o problema de leitura. Ela não resolveu o problema de montagem.

O processamento em lote resolve ambos simultaneamente porque trata as trinta faturas como uma unidade de trabalho — extraindo os dados de todos os trinta documentos em uma única execução e produzindo saídas estruturadas para sistemas downstream, não apenas para um humano visualizar.

O Fluxo de Trabalho em Lote: Defina Uma Vez, Processe Todo Mês

O esquema de colunas para processamento em lote de faturas japonesas é definido uma vez. Os mesmos vinte e poucos nomes de colunas — Número da Fatura (請求書番号), Data de Emissão (発行日), Fornecedor (発行元), Número de Registro de Fatura Qualificada (インボイス登録番号), Nome do Item (品名), Quantidade (数量), Preço Unitário (単価), Valor da Linha (金額), Subtotal (小計), Valor Tributável a 10%, Imposto sobre Consumo a 10%, Valor Tributável a 8%, Imposto sobre Consumo a 8%, Total (合計金額), Classificação de Retenção na Fonte (源泉徴収区分), Nome do Banco (振込先銀行名), Nome da Agência (支店名), Tipo de Conta (口座種別), Número da Conta (口座番号), Titular da Conta (口座名義), Condições de Pagamento (支払条件), Dia de Fechamento (締日), Responsabilidade pela Taxa de Transferência (振込手数料負担) — são digitados uma vez. A cada mês seguinte, a equipe de contas a pagar insere a pilha de PDFs de faturas do fechamento do mês no upload, o lote processa todos os documentos simultaneamente, e a planilha de saída chega com todas as trinta linhas preenchidas. Os nomes das colunas não mudam. Os formatos de fatura dos fornecedores podem mudar — um novo sistema ERP em um fornecedor, uma migração de plataforma de faturamento em outro — mas a IA lê cada documento entendendo o que cada campo significa, não lembrando onde cada fornecedor coloca seus dados bancários na página.

Este esquema captura a Extração de Colunas Personalizadas: você digita os nomes das colunas que deseja na saída, e a IA localiza os dados correspondentes em cada documento entendendo o significado do campo — não confiando em uma posição fixa que varia de um layout de fatura de fornecedor para outro. Uma coluna calculada pode derivar valores adicionais durante a extração: uma coluna como Valor Líquido do Pagamento (se houver Retenção na Fonte: Total × 0,8979; senão: Total) calcula o valor real da transferência diretamente. Uma coluna inferida pode converter o texto compacto das condições de pagamento em valores estruturados: Dia de Fechamento (das Condições de Pagamento: se "20日締" então 20) e Meses de Atraso no Pagamento (se "翌月末払い" então 1) — dividindo a string de texto "20日締翌月末払い" em dois números computáveis que uma fórmula de calendário de pagamentos pode ler diretamente.

Saída 1: Dados Bancários Viram um Lote de Pagamentos

A tarefa de entrada de dados mais repetitiva no contas a pagar japonês é redigitar os dados bancários da fatura no sistema de internet banking. Cada fatura traz um bloco de dados bancários com quatro campos separados: Nome do Banco, Nome da Agência, Tipo de Conta (普通 para ordinária ou 当座 para corrente) e Número da Conta. O funcionário lê esses quatro campos na fatura, alterna para a tela de internet banking do banco e os digita — os mesmos quatro campos já armazenados no cadastro de fornecedores do sistema contábil, redigitados para cada fatura todo mês. Trinta faturas no fechamento do mês: 120 entradas individuais de campos bancários que duplicam dados já registrados.

Quando a saída em lote contém cada um dos quatro campos bancários em sua própria coluna — Nome do Banco, Nome da Agência, Tipo de Conta, Número da Conta — essas colunas são a entrada para um arquivo de lote de pagamentos. Os bancos japoneses aceitam arquivos de transferência em lote no formato 全銀フォーマット (formato Zengin), um formato de largura fixa padronizado pela Rede de Compensação de Pagamentos dos Bancos Japoneses (全国銀行資金決済ネットワーク) que permite que uma empresa envie múltiplas transferências em um único upload, em vez de inseri-las uma a uma pela tela de internet banking. O formato exige, para cada transferência: o código da agência remetente, o número da conta remetente, o código do banco beneficiário, o código da agência beneficiária, o número da conta beneficiária, o nome do beneficiário e o valor da transferência — tudo em posições de caracteres precisas.

Uma planilha com trinta linhas, cada uma contendo nome do banco, nome da agência, tipo de conta, número da conta, titular da conta e valor líquido a pagar em colunas separadas, pode ser mapeada para o formato Zengin por meio de um modelo simples. Os dados já estão estruturados — o mapeamento é uma exportação única de planilha para largura fixa, não trinta rodadas de redigitação de códigos bancários. A mesma abordagem se aplica à transferência consolidada, onde uma única instrução de transferência cobre múltiplos pagamentos de uma única conta da empresa — o método mais comum para empresas japonesas pagarem várias faturas de fornecedores no mesmo dia de liquidação. Os dados bancários extraídos, agrupados por dia de liquidação, formam a entrada para um lote de transferência consolidada: todas as faturas com fechamento no dia 20 e vencimento no fim do mês vão para uma instrução de transferência; todas as faturas com fechamento no fim do mês e vencimento no mês seguinte vão para outra.

Saída 2: Prazos de Pagamento Viram um Calendário de Vencimento

O campo de prazos de pagamento em uma fatura japonesa é uma string de texto compacta que as equipes de AP leem com fluência, mas que resiste ao processamento por fórmulas. "20日締翌月末払い" — fechamento no dia 20, pagamento até o final do mês seguinte. "末日締翌々月10日払い" — fechamento no fim do mês, pagamento até o dia 10 do mês seguinte ao próximo. "15日締翌月末払い" — fechamento no dia 15, pagamento até o final do mês seguinte. Cada string codifica dois valores: um dia de fechamento (締日) e um prazo de pagamento. Em um fluxo de arquivo único, uma pessoa lê a string de cada fatura, calcula mentalmente a data de vencimento e a insere em um calendário. Em um fluxo em lote, uma coluna calculada analisa essas strings em números estruturados — Dia de Fechamento e Meses de Prazo de Pagamento — e a planilha agrupa os pagamentos automaticamente por dia de fechamento.

Esse agrupamento é importante porque controla a saída de caixa. Faturas fechadas no dia 20 e pagáveis no final do mês seguinte consomem caixa no mesmo dia. Faturas fechadas no fim do mês e pagáveis no final do mês seguinte consomem caixa duas a três semanas depois, em um dia diferente. Sem o agrupamento em lote, a equipe de AP vê trinta datas de vencimento individuais. Com o agrupamento em lote, a equipe de AP vê dois ou três dias de saída de caixa com valores totais anexados — a informação que o departamento de tesouraria realmente precisa para gerenciar o capital de giro. O dia de fechamento, não a data da fatura ou o mês do calendário, determina a qual período fiscal a despesa pertence. Uma fatura datada de 18 de março com condições 20日締 é uma despesa de março — paga em abril, mas acumulada no ano fiscal que termina em 31 de março. Uma fatura datada de 22 de março com as mesmas condições 20日締 é uma despesa de abril — paga em maio, acumulada no próximo ano fiscal. O dia de fechamento é o limite do período fiscal, e a saída em lote agrupa automaticamente por esse limite porque a coluna calculada o extraiu como um número.

Saída 3: Totais de Imposto sobre Consumo Alimentam Diretamente a Declaração de Imposto

O sistema de imposto sobre consumo do Japão aplica duas alíquotas — 10% padrão e 8% reduzida — e o sistema de Fatura Qualificada exige que cada fatura declare a base tributável e o valor do imposto por categoria de alíquota separadamente. Para uma empresa que usa o método de acumulação (積上げ計算) para a declaração do imposto sobre consumo, a declaração exige os dados de imposto por fatura — não apenas um subtotal agregado, mas os valores individuais de imposto de cada fatura qualificada, preservados no nível do documento.

A saída em lote captura o valor tributável a 10%, o imposto sobre consumo a 10%, o valor tributável a 8% e o imposto sobre consumo a 8% de cada fatura em colunas separadas. A planilha entrega totais agrupados por alíquota que podem ser verificados em relação ao detalhamento do imposto impresso em cada fatura — a mesma verificação que a equipe de AP faria manualmente em cada fatura, mas realizada automaticamente em todas as trinta faturas em uma única saída. Se o total do imposto sobre consumo a 8% extraído de uma fatura diferir do total impresso no documento, a discrepância é sinalizada na planilha para revisão. A pilha de trinta faturas se torna uma lista de verificação em vez de trinta tarefas de verificação individuais, e os totais agrupados por alíquota formam a entrada para a declaração trimestral do imposto sobre consumo sem exigir uma passagem separada de agregação manual.

Saída 4: Retenção na Fonte Vira Valor Líquido a Pagar

O sistema de retenção na fonte do Japão (源泉徴収制度), regido pelo Artigo 204 da Lei do Imposto de Renda (所得税法), exige que o pagador deduza o imposto de renda na fonte ao efetuar pagamentos a certos prestadores de serviços profissionais — contadores fiscais (税理士), contadores públicos certificados (公認会計士), advogados (弁護士), escrivães judiciais (司法書士), designers (デザイナー), escritores (著作家) e outras categorias qualificadas. A alíquota de retenção é de 10,21% para pagamentos de até ¥1 milhão e de 20,42% para o valor que exceder ¥1 milhão, conforme confirmado pelo guia de retenção na fonte da Agência Tributária Nacional. O pagador recolhe o valor retido à repartição fiscal e paga ao fornecedor o saldo restante.

Uma fatura de um fornecedor qualificado que contenha uma classificação de retenção na fonte — geralmente marcada como 源泉徴収あり ou exibindo uma linha separada de "源泉徴収額" — altera o cálculo do pagamento. A equipe de contas a pagar deve identificar quais faturas exigem retenção, calcular o valor da dedução por fatura, subtraí-lo do pagamento e contabilizar o valor retido como um passivo separado de depósito de imposto. Em um fluxo de arquivo único, isso é aritmética manual por fatura qualificada. Em um fluxo em lote, duas colunas cuidam disso:

• Classificação de Retenção na Fonte — uma coluna inferida que verifica se a fatura menciona 源泉徴収 e se o fornecedor é um profissional qualificado. Saída: "Aplicável" ou "Não Aplicável".
• Valor Líquido a Pagar — uma coluna calculada: se a retenção for aplicável e o total for inferior a ¥1 milhão, saída Total × 0,8979. Gera o valor real da transferência para cada fatura.

A planilha chega com três colunas por fatura qualificada: Valor Bruto (total da fatura), Valor da Retenção (a dedução) e Valor Líquido a Pagar (o valor da transferência). O arquivo do lote de pagamento usa o Valor Líquido a Pagar. O cronograma de depósito de imposto usa o Valor da Retenção. Ambos extraem dos mesmos dados de origem — extraídos uma vez, calculados uma vez, disponíveis tanto para pagamento quanto para conformidade. A mesma abordagem de processamento em lote para ordens de compra japonesas captura os mesmos termos de pagamento e campos de retenção do lado da aquisição, criando um pipeline correspondente entre o que foi pedido e o que está sendo faturado.

A Cadeia do Número da Fatura: Do PDF à Confirmação de Pagamento

O número da fatura (請求書番号) é a chave primária para consultas de contas a pagar e rastreamento de pagamentos. Quando uma confirmação de pagamento chega do banco — um registro de transação mostrando uma furikomi de ¥847.200 para o Mitsubishi UFJ Bank, Agência Shinjuku, conta 1234567 — a equipe de contas a pagar precisa vinculá-la à fatura original para confirmar que o valor correto foi para a conta certa referente à fatura certa. Sem o número da fatura, associar uma transação bancária a uma fatura de fornecedor se torna um problema de conciliação que se agrava com o volume: trinta pagamentos a fornecedores por mês, doze meses por ano, 360 possíveis divergências.

A saída em lote carrega o número da fatura em uma coluna dedicada. Cada confirmação de pagamento do banco pode ser associada à planilha do lote pelo número da fatura — e não pelo valor, que pode ser ambíguo quando duas faturas têm o mesmo total — criando uma trilha de auditoria desde o PDF da fatura original, passando pela planilha de extração, até o registro de pagamento bancário. O número de registro de fatura qualificada (インボイス登録番号), extraído junto com o número da fatura, fornece um segundo ponto de verificação: o número T nos dados extraídos deve corresponder ao número T no cadastro do fornecedor. Uma divergência sinaliza um fornecedor cujo status de registro pode ter mudado — um dado que, em um fluxo manual, passaria despercebido até que a declaração de imposto sobre o consumo acione uma consulta de auditoria.

Essa cadeia — número da fatura → transferência bancária → confirmação de pagamento — é o que transforma trinta furikomi individuais em um único exercício de conciliação. O lote não apenas extrai dados mais rápido. Ele cria a estrutura de vinculação que torna trinta pagamentos reconciliáveis como um grupo, em vez de trinta investigações separadas. O mesmo princípio de vinculação do lado da aquisição impulsiona o fluxo de correspondência entre pedido de compra, entrega e fatura e a abordagem trimestral em lote do BAS australiano — a saída da extração não é um ponto final, mas um ponto intermediário em uma cadeia de documentos que começa com um pedido de compra e termina com uma declaração de imposto.

FAQ

O lote consegue processar faturas de fornecedores que usam formatos de faturamento diferentes?

Sim. O esquema de colunas é definido uma vez e aplicado a todas as faturas do lote, independentemente do layout. Um fornecedor pode usar um PDF gerado pelo seu sistema ERP com os dados bancários em uma caixa com bordas no final da página. Outro pode enviar uma fatura manuscrita escaneada onde os dados bancários aparecem na seção de observações. A IA lê cada documento entendendo o significado de cada campo — um nome de banco é um nome de banco onde quer que apareça — e não esperando um layout fixo por fornecedor. As trinta faturas podem vir de trinta sistemas de faturamento diferentes em trinta formatos distintos, e a saída é uma única planilha consistente.

Como o lote lida com o formato de conta da ゆうちょ銀行?

O Japan Post Bank (ゆうちょ銀行) usa um formato 記号-番号 que difere dos números de conta de 7 dígitos usados pelos bancos comerciais para transferências furikomi. Quando a saída do lote detecta ゆうちょ銀行 como nome do banco, uma coluna inferida pode converter o par 記号-番号 para o número de conta de transferência de 7 dígitos exigido pelo sistema bancário. O Japan Post Bank publica a regra de conversão em seu site. A lógica da coluna analisa os dígitos de 記号 e 番号 e gera o número de conta pronto para transferência junto com o formato original para verificação.

E se algumas faturas forem com imposto incluído (税込) e outras sem imposto (税抜)?

A definição da coluna deve especificar a normalização desejada na saída. Se os preços unitários forem com imposto incluído em algumas faturas de fornecedores e sem imposto em outras, uma coluna calculada os normaliza durante a extração: Valor do Item Sem Imposto (se a notação da fatura for 税込, dividir o preço unitário por 1,1 para itens de 10% ou 1,08 para itens de 8%; caso contrário, usar como está). A IA lê o contexto do documento — incluindo qualquer notação 税込 ou 税抜 — para determinar o tratamento do imposto e gerar todos os valores dos itens em uma base consistente. A planilha chega com cada linha normalizada, de modo que os totais de imposto sobre consumo de todas as trinta faturas são calculados a partir de uma base uniforme.

Como a coluna de retenção na fonte (源泉徴収) interage com o cálculo do imposto sobre consumo?

De acordo com a orientação da NTA, se a remuneração e o imposto sobre consumo estiverem claramente separados na fatura, a retenção é calculada apenas sobre o valor da remuneração — a parcela do imposto sobre consumo não está sujeita à retenção. Se não estiverem separados, o valor com imposto incluído é geralmente usado para o cálculo da retenção. A definição da coluna deve especificar a regra de cálculo: Base de Retenção (se a fatura separa claramente 報酬 e 消費税, usar 報酬; caso contrário, usar Total) e Valor da Retenção (Base de Retenção × 0,1021, limitado a Base de Retenção × 0,1021 para valores de até ¥1M). O lote aplica a mesma regra a todas as trinta faturas, garantindo que o cálculo da retenção seja consistente e auditável.

O resultado do lote pode ser importado diretamente para softwares de contabilidade japoneses?

Sim. Todas as principais plataformas de contabilidade japonesas — 弥生会計 (Yayoi), freee, マネーフォワード クラウド会計 (MoneyForward Cloud), 勘定奉行 (Kanjo Bugyo) — aceitam importação CSV de dados do livro de compras. O resultado do lote mapeia diretamente: Número da Fatura → número do voucher (伝票番号), Fornecedor → nome do vendedor (仕入先), Data de Emissão → data da transação (日付), Total → valor (金額). As colunas de imposto sobre consumo por faixa de alíquota alimentam o módulo de declaração fiscal. O número de registro de fatura qualificada (インボイス登録番号) flui para a verificação de fatura qualificada que plataformas como freee realizam automaticamente. Os dados bancários da transferência — em colunas separadas — formam a entrada para o arquivo de pagamento em lote do banco, independentemente da importação do software de contabilidade.

De Trinta PDFs a um Livro-Razão Pronto para Pagamento

A pilha de faturas no final do mês em uma empresa japonesa não é simplesmente trinta contas a pagar. São trinta instruções de pagamento — cada uma com dados bancários que precisam ser redigitados no sistema bancário. São trinta documentos fiscais — cada um com valores de imposto sobre consumo por faixa de alíquota que alimentam a declaração trimestral. São trinta registros de conformidade — alguns com obrigações de retenção na fonte que exigem depósitos fiscais separados. E são trinta artefatos de conciliação — números de fatura que devem se alinhar com pedidos de compra, confirmações de entrega e registros de pagamento bancário.

Um fluxo de trabalho de extração em lote que processa todas as trinta faturas como uma unidade de trabalho produz não trinta linhas individuais de planilha, mas quatro resultados prontos para uso: um arquivo de pagamento em lote com dados bancários já em colunas prontas para transferência, um calendário de pagamentos agrupado por data de liquidação, um resumo do imposto sobre consumo por faixa de alíquota para a declaração fiscal e uma programação de retenção com valores líquidos de pagamento já calculados. A tarefa de fim de mês da equipe de contas a pagar passa de entrada de dados para verificação de dados — de digitar os mesmos quatro campos bancários trinta vezes para verificar se trinta linhas extraídas correspondem aos documentos de origem. A planilha é o resultado. A planilha também é a entrada — para o sistema de pagamento bancário, o software de contabilidade e a declaração fiscal. O lote os conecta produzindo dados na estrutura que cada sistema downstream espera, não produzindo dados que um humano precise reformatar antes de cada transferência.