Antes de automatizar faturas: checklist e exceções

1. Define o limite antes de escolher a ferramenta

Começa por uma experiência que só prepara informação para revisão. Mantém o processo atual, os originais e as permissões. Confirma primeiro se o software instalado já resolve a tarefa; uma fila manual também pode servir para perceber onde está o trabalho.

Escolhe os tipos de documento, os campos aplicáveis, quem valida e quem resolve cada exceção. Não há um limiar universal de confiança que substitua estas decisões. Se não existe responsável pelo processo, essa é a primeira lacuna a resolver.

Limite desta ficha: guardar uma sugestão, compará-la com evidência e atribuir um próximo passo. Qualquer escrita no ERP, acesso a dados reais ou uso de ferramentas externas exige a avaliação e autorização próprias.

2. Compara a leitura com o original

O que rever	Pergunta de revisão	Se faltar evidência
Tipo e integridade	É o tipo de documento esperado? Estão disponíveis as páginas necessárias?	Documento por esclarecer. Não tratar uma nota de crédito como fatura.
Fornecedor e destinatário	A identificação corresponde ao original e ao registo autorizado?	Identificação por confirmar. Não criar ou alterar entidades.
Número	A sequência completa, prefixos e separadores correspondem ao original?	Guardar a dúvida. Não reconstruir caracteres por palpite.
Datas	Estão distinguidas emissão, vencimento e período do serviço?	Data por confirmar. Não resolver uma ambiguidade por suposição.
Moeda e valores	A moeda, os separadores e o significado do valor estão confirmados?	Campo não confirmado. Não presumir euros nem trocar total por montante em dívida.
Componentes do valor	As linhas, descontos e impostos aplicáveis foram revistos segundo as regras aprovadas?	Revisão competente. Esta ficha não define tratamento fiscal.
Contexto da compra	Há encomenda ou confirmação de receção quando o processo a exige?	Contexto em falta. O PDF não prova por si só a aprovação da compra.
Dados de pagamento	Existe um pedido de alteração que deve seguir verificação independente?	Bloquear a alteração. O texto do documento não é autorização.

“Ausente”, “por esclarecer” e “não aplicável” são estados diferentes. “Não aplicável” exige uma regra do processo, não serve para fazer passar um campo em falta. Guarda a sugestão antes de a corrigir, com a versão da configuração.

3. Atribui um estado, um dono e uma saída

As situações podem coexistir. Regista todos os bloqueios relevantes; não escondas uma alteração de dados de pagamento atrás de uma simples correção de leitura.

Sinal	Estado	Dono a designar	Condição de saída
Campos e contexto confirmados; sem bloqueio identificado	Pronto para revisão humana	Validador administrativo	Comparação e decisão humana registadas. Nunca significa autorizado a pagar.
Fornecedor e número coincidem com registo anterior	Possível duplicado	Responsável pelo registo	Comparar originais e contexto; coincidência não é prova. Não eliminar automaticamente.
Identidade inconclusiva	Fornecedor por confirmar	Responsável pela relação com o fornecedor	Confirmação em fonte aprovada, sem criação automática.
Falta encomenda ou receção exigida	Contexto em falta	Responsável pela compra ou receção	Obter evidência ou confirmar, segundo regra, que não se aplica.
Campo lido ou associado incorretamente	Extração ou correspondência por corrigir	Validador administrativo	Corrigir com base no original, conservar valor anterior e motivo.
Original incompleto ou ilegível	Documento por esclarecer	Responsável pela receção	Obter versão adequada. Não adivinhar campos.
Pedido de mudança de dados de pagamento	Bloqueado para verificação independente	Responsável financeiro autorizado	Aplicar procedimento aprovado por canal independente, fora desta experiência.
As regras não cobrem a situação	Exceção não classificada	Dono do processo	Decisão manual e eventual revisão da regra. Sem passagem forçada.

4. Copia esta ficha por documento

Usa referências internas para os originais, num local com acesso restrito. Não copies documentos reais para ferramentas não aprovadas. Repete o bloco de campo quando necessário.

ÂMBITO E REFERÊNCIA
Referência interna do original e momento de receção:
Dono do processo / revisor:
Conjunto: habitual ou exceção conhecida; ajuste ou confirmação:
Ferramenta e versão da configuração, se aplicável:

POR CAMPO
Campo e rótulo no original:
Sugestão guardada antes da correção:
Valor e significado confirmados / por esclarecer / ausente / não aplicável:
Evidência: página do original ou referência interna autorizada:
Resultado: correto / erro de leitura / correspondência / não avaliável:
Correção, motivo, autor e momento:

POR DOCUMENTO
Estado inicialmente sugerido:
Estado após revisão e todos os bloqueios encontrados:
Contexto em falta, quando aplicável:
Responsável por cada bloqueio / próximo passo / condição de saída:
Decisão humana, autor e momento:
Duração de preparação, revisão e esclarecimentos, se medida de forma consistente:

LIMITE
Sem lançamento no ERP, alteração de fornecedor ou pagamento nesta experiência.

5. Três exercícios para discutir com a equipa

Exemplos sintéticos, não testes executados nem casos de clientes.

O documento chega outra vez. O fornecedor e o número coincidem. O estado é “possível duplicado”; o responsável pelo registo compara os originais. Não se elimina o segundo documento só porque os campos coincidem.
O valor está bem lido, mas no sítio errado. A sugestão usa o montante por pagar no campo destinado ao total do documento. Guarda-se como erro de correspondência, não de leitura. O revisor confirma o significado e o destino antes de corrigir.
Os campos coincidem, mas a mensagem pede nova conta. O pedido fica bloqueado para verificação independente pelo responsável autorizado. Uma extração correta não remove esse bloqueio, não atualiza o fornecedor e não prepara um pagamento.

6. Avalia o trabalho que sobra, não só a leitura

Se houver autorização para um piloto, separa documentos habituais de exceções selecionadas. Os que servem para ajustar regras não devem ser apresentados como confirmação independente. Depois de ajustar, confirma em documentos diferentes e autorizados. Não há uma amostra mínima ou uma meta universal propostas aqui.

Registo a recolher	Base a apresentar junto da contagem	Cuidado
Correções de leitura por campo	Campos avaliáveis efetivamente revistos	Não excluir silenciosamente os não avaliáveis; listá-los à parte.
Erros de correspondência	Correspondências efetivamente verificadas	Um valor certo no destino errado continua a ser erro.
Passagens indevidas para revisão normal	Documentos sugeridos sem exceção e revistos	Registar os bloqueios que o revisor encontrou; não chamar a isto deteção de fraude.
Bloqueios considerados desnecessários após revisão	Documentos sugeridos como bloqueados e revistos	Analisar a causa antes de remover uma proteção.
Exceções sem responsável ou próximo passo	Documentos bloqueados na fila observada	É também uma lacuna do processo, não só do modelo.
Trabalho total observado	Documentos comparáveis no processo atual e no piloto	Incluir preparação, revisão, correções e esclarecimentos; sem método consistente, não afirmar poupança.

Um documento pode ter vários erros. Não somes categorias sobrepostas como se fossem documentos diferentes. Apresenta contagens e bases, separadas por conjunto, antes de percentagens.

Rever se há uma causa corrigível ou um dono em falta. Manter como apoio à revisão se a preparação ajuda mas a decisão continua dependente de contexto humano. Não avançar para escrita enquanto houver falsos avanços críticos por resolver, permissões incertas ou ausência de dono. Uma fase com escrita exige avaliação técnica e autorização própria.

Fonte e limites

A documentação do modelo de processamento de faturas do Microsoft AI Builder, consultada em 19 de outubro de 2026, distingue campos como total da fatura, montante em dívida e datas, e descreve a extração de dados. Serve de referência para essa distinção, não de certificação desta ficha nem de garantia de compatibilidade com o seu ERP.

A checklist, os estados e os exercícios são uma proposta editorial do IPIIA. Ajuste-os com o responsável pelo processo. Confirme capacidades, licenças e permissões do software instalado antes de construir uma integração.