Qual valor prevalece quando
o XML da nota fiscal ZATCA e o PDF divergem
Uma nota fiscal ZATCA pode conter SAR 230 com VAT incluído e SAR 126 a pagar, e ambos os números podem estar corretos. A diferença é um adiantamento de SAR 104 já recebido, mantido no XML como valor pré-pago e frequentemente exibido na página como uma linha separada de adiantamento ou saldo. Uma coluna de planilha chamada "Total" pode conter apenas um deles. Lance o errado e o fornecedor será pago duas vezes pelo mesmo adiantamento.
Essa é a forma da extração de XML de nota fiscal ZATCA em contas a pagar. O arquivo não é um único documento. É um payload UBL 2.1 assinado que carrega o registro fiscal, uma página PDF/A-3 que carrega o que uma pessoa lê, e um código QR que carrega um resumo de cinco valores de negócio. Eles concordam onde a ZATCA os projetou para concordar e divergem em tudo o que o AP precisa de contexto operacional. O trabalho é um mapa de autoridade em nível de campo mais um caminho de exceção registrado. Um parser sozinho não produz nenhum dos dois.

Principais conclusões
- SAR 230 com VAT incluído e SAR 126 a pagar podem ambos estar corretos em uma única nota fiscal ZATCA, porque um adiantamento de SAR 104 está no XML.
- O XML assinado é a nota fiscal e o PDF/A-3 é apenas uma renderização, então a página impressa pode divergir sem que nenhum dos registros esteja errado.
- Extraia o líquido da linha declarada e o valor a pagar como colunas próprias, e a divergência se torna uma fila de revisão em vez de um erro de pagamento.
Uma fatura ZATCA são dois registros em um único contêiner

O XML assinado é a fatura; o PDF/A-3 é uma renderização que pode carregá-lo. A ZATCA, a Zakat, Tax and Customs Authority, exige que toda fatura da Phase 2 seja gerada e armazenada como XML ZATCA UBL 2.1, ou como um arquivo PDF/A-3 com esse XML incorporado. O XML é o objeto que é assinado e depois liberado pela ZATCA antes que uma fatura padrão chegue ao comprador, ou reportado em até 24 horas no caso de uma fatura simplificada. O PDF é a cópia legível por humanos.
O ZATCA Detailed Guidelines for E-Invoicing responde à pergunta comum de forma direta: se um contribuinte quiser enviar um PDF, o PDF/A-3 com XML incorporado é obrigatório. Na Phase 2, um PDF simples, um arquivo do Word ou um scan não é uma fatura eletrônica compatível. A cópia legível por humanos também precisa estar em árabe, com qualquer idioma adicional permitido ao lado. É por isso que o mesmo nome de fornecedor pode aparecer duas vezes, uma em árabe e outra em inglês, e por que as duas versões não são intercambiáveis em uma regra de correspondência.
UBL 2.1 é o padrão XML da OASIS por trás do formato. Seus elementos vêm em duas famílias: cbc para valores como ID, IssueDate e TaxAmount, e cac para contêineres como AccountingSupplierParty e InvoiceLine. Os prefixos familiares são aliases. Um fornecedor pode usar nomes de prefixo diferentes para o mesmo namespace, então um parser deve resolver namespaces em vez de corresponder à string cbc:. O ZATCA XML Implementation Standard acrescenta as regras sauditas sobre o UBL e a EN 16931.
PDF/A-3 é uma variante de PDF de arquivamento que permite arquivos incorporados. Uma fatura híbrida é uma página de aparência normal mais um anexo. O anexo é o que você faz o parse; a página é o que uma pessoa lê. O código QR é um terceiro registro, menor: uma string Base64 de registros tag-length-value, de até 500 caracteres. As tags 1 a 5 carregam o nome do vendedor, o número de VAT do vendedor, o timestamp, o total com VAT e o total de VAT; as tags 6 a 9 carregam o hash, a assinatura, a chave pública e, em faturas simplificadas, a assinatura da ZATCA sobre essa chave. O programa de faturamento eletrônico da ZATCA se chama Fatoora (فاتورة).
Um PDF com código QR não é prova de que o XML está dentro dele. A extensão descreve o contêiner, não o seu conteúdo. Verifique a coleção de anexos antes de decidir qual registro você está lendo.
O que Realmente Chega a uma Caixa de Entrada de AP
A extensão não diz quase nada; a coleção de anexos diz o que você pode analisar. O ERP de um fornecedor pode produzir um híbrido correto e o comprador ainda pode receber um PDF achatado. Portais de compras renderizam novamente os anexos, gateways de e-mail os removem e os auxiliares de AP imprimem em PDF antes de arquivar. A fatura na caixa de entrada pode parecer perfeita e estar estruturalmente vazia. O relatório anual de 2025 da ZATCA coloca o volume de faturas eletrônicas do ano acima de 8 bilhões, então uma caixa de entrada mista não é um caso isolado. Os quatro estados abaixo exigem tratamentos diferentes.
| O que chegou | O que você pode analisar | Primeira verificação | Nível de confiança |
|---|---|---|---|
.xml bruto | O próprio payload da fatura | Bem formado, raiz Invoice, namespaces esperados, checksum dos bytes recebidos | Analisado |
| PDF/A-3 com um anexo XML acessível | O payload incorporado | O anexo abre, é analisado como XML e a página corresponde aos valores que você verifica por amostragem | Analisado |
| PDF/A-3 sem anexo XML utilizável | Pixels, não caracteres, se a página for apenas imagem | Anexo ausente, corrompido ou ilegível; o texto pode não ser selecionável | Observado |
| PDF simples, JPG ou PNG | Texto selecionável ou pixels | Sem anexo; um código QR ainda pode estar impresso na página | Observado |

O inverso também acontece. O fórum de desenvolvedores da ZATCA tem um tópico de um fornecedor perguntando se os valores podem ser fornecidos como uma imagem em um PDF/A-3. O arquivo declara conformidade, mas os caracteres não podem ser selecionados ou copiados porque não há fontes, apenas pixels. Nesse caso, o XML incorporado é a única camada legível por máquina, e o OCR se torna um recurso de fallback em vez de um padrão. O tópico do fórum é um lembrete útil de que "PDF/A-3" descreve o contêiner, não a legibilidade da página.
Verifique o anexo, não o nome do arquivo. Abra o painel de anexos em um leitor de PDF, ou inspecione a entrada /AF, extraia o arquivo para uma pasta de trabalho controlada, confirme que ele é analisado como XML e deixe os bytes originais intactos. Se o anexo estiver ausente, corrompido ou inacessível, registre essa condição antes de usar a página. Os quatro estados acima não são equivalentes, e tratar uma página observada como um payload analisado é o primeiro lugar onde uma exceção de AP se perde.
Os Campos Que Decidem o Pagamento
O AP precisa de cerca de uma dúzia de campos de cabeçalho e cinco por linha, e o XML nomeia cada um deles. Depois que o artefato é triado, a lista de campos é a mesma, quer os valores venham de um parser ou de uma página. A tabela é um mapa de trabalho, não o dicionário de dados completo. Ela mantém os campos que alteram um pagamento, um lançamento fiscal ou uma verificação de duplicidade, e deixa de fora os que só importam para o desembaraço do vendedor. Os caminhos são relativos à raiz Invoice.
| Campo do AP | Caminho UBL | O PDF geralmente mostra | Autoridade |
|---|---|---|---|
| Razão social do fornecedor | cac:AccountingSupplierParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName | Bloco de nome bilíngue | XML |
| Número de VAT do vendedor | .../cac:PartyTaxScheme/cbc:CompanyID | 15 dígitos, começando e terminando em 3 | XML, conferir tag 2 do código QR |
| Razão social e número de VAT do comprador | cac:AccountingCustomerParty/... | Bloco do comprador; opcional em faturas simplificadas | XML |
| Número da fatura | cbc:ID | Canto superior ou linha do cabeçalho | XML |
| UUID | cbc:UUID | Geralmente não é impresso | Somente XML |
| Data e hora de emissão | cbc:IssueDate, cbc:IssueTime | Data, raramente a hora | XML |
| Tipo de fatura | cbc:InvoiceTypeCode e seu atributo name | "Tax Invoice" ou "Simplified" | XML |
| Moeda e moeda do imposto | cbc:DocumentCurrencyCode, cbc:TaxCurrencyCode | Símbolo ou código da moeda | XML |
| PO, nota de entrega, data de vencimento | cac:OrderReference/cbc:ID, cac:Delivery, cac:PaymentTerms | Geralmente impresso | Página quando o XML omite |
| Quantidade e unidade da linha | cac:InvoiceLine/cbc:InvoicedQuantity e unitCode | Coluna de quantidade | XML |
| Preço unitário e quantidade base | cac:InvoiceLine/cac:Price/cbc:PriceAmount, cbc:BaseQuantity | Coluna de preço unitário | XML |
| Abatimento ou encargo da linha | cac:InvoiceLine/cac:AllowanceCharge/cbc:Amount | Coluna de desconto ou nota de rodapé | XML |
| Líquido declarado da linha | cac:InvoiceLine/cbc:LineExtensionAmount | Total da linha | XML |
| Categoria e alíquota de VAT da linha | cac:InvoiceLine/cac:Item/cac:ClassifiedTaxCategory/cbc:ID (S, Z, E ou O) e cbc:Percent | "15%", "Zero-rated" ou "Exempt" | XML |
| Imposto e totais | cac:TaxTotal/cbc:TaxAmount; cac:LegalMonetaryTotal | Subtotal, VAT, total, valor a pagar | XML, página para conferência visual |
| Referência da nota de crédito | cac:BillingReference/cac:InvoiceDocumentReference/cbc:ID | "Against invoice ..." | XML |
Duas regras tornam o mapa utilizável. Extraia LineExtensionAmount e PayableAmount como colunas próprias mesmo quando você também extrai quantidade e preço. Recalcular um valor que o documento já declara é como o AP cria uma divergência que não existe. Mantenha também a string bruta ao lado do valor normalizado. Um número de fatura com zero à esquerda, um nome legal em árabe e um carimbo de data/hora em Arabia Standard Time perdem informação quando são forçados cedo demais. Nomes em árabe também podem ser exibidos em uma ordem visual diferente mesmo quando os caracteres estão corretos, então mantenha a string bruta e defina a direção de exibição em vez de redigitar o valor. Se a divisão entre cabeçalho e linha é novidade para você, o guia completo de extração de dados de faturas cobre o modelo geral.
Onde as Duas Camadas Realmente Divergem

A maioria das divergências não é corrupção. São duas renderizações corretas de campos diferentes. Os cinco casos abaixo explicam a maior parte das exceções de AP que parecem erros de dados, mas na verdade são erros de mapeamento.
Um desconto de linha altera o líquido da linha, não o preço unitário
O padrão de implementação da ZATCA define o líquido da linha como ((preço líquido do item ÷ quantidade base) × quantidade faturada) menos abatimento de linha mais encargo de linha. Uma linha com 10 unidades a SAR 100 e um abatimento de linha de SAR 50 tem um líquido de linha de SAR 950, enquanto o preço unitário impresso permanece SAR 100. Se o PDF mostra o preço unitário e o total da linha, mas não o abatimento, a página parece aritmeticamente errada. Não está. O abatimento fica no XML, dentro de cac:InvoiceLine/cac:AllowanceCharge.
Se o AP extrai quantidade e preço unitário e calcula um total de linha, obtém SAR 1.000 contra um documento que diz SAR 950. A fatura então falha em uma verificação que deveria ter passado, ou um funcionário ajusta o campo errado para fazê-la fechar. Extraia o líquido da linha declarado e mantenha o abatimento em sua própria coluna para que a aritmética possa ser reproduzida depois.
Uma coluna calculada é útil para conferência. Não substitui o líquido da linha que o documento declara.
Um pré-pagamento divide o total em dois números
O próprio exemplo de pré-pagamento da ZATCA mostra o padrão: SAR 230 incluindo VAT, SAR 104 já pré-pago, SAR 126 a pagar. TaxInclusiveAmount é 230, PrepaidAmount é 104, PayableAmount é 126. Todos os três estão corretos, e cada um responde a uma pergunta diferente. Mapeie o valor devido para PayableAmount, o valor da fatura para TaxInclusiveAmount e o adiantamento para sua própria coluna. Se o ERP tem um único campo de total, coloque o valor da fatura nele e leve o valor a pagar no cronograma de pagamentos. Sobrescrever um com o outro oculta o adiantamento e o paga duas vezes.
Uma fatura em moeda estrangeira carrega dois totais de imposto
Quando a moeda do documento não é SAR, a ZATCA exige que TaxCurrencyCode seja SAR e um segundo total de imposto em SAR. O PDF frequentemente imprime apenas a moeda do documento. Uma equipe de AP que converte o total impresso a uma taxa de fim de mês obterá um valor de VAT em SAR diferente do que está no XML, e a diferença cai na conta de recuperação de VAT. Leia os dois totais de imposto, lance o de SAR e mantenha o da moeda do documento para o razão do fornecedor.
O PDF pode conter campos que o XML não é obrigado a incluir
O padrão da ZATCA é um mínimo. No fórum de desenvolvedores do Fatoora, um fornecedor perguntou se informações extras impressas no PDF/A-3 precisavam aparecer no XML. A resposta foi que campos fora do dicionário de dados não são exigidos no XML, embora possam ser adicionados se estiverem em conformidade com o UBL. É aí que costumam ficar números de pedido de compra, referências de notas de entrega, centros de custo internos e carimbos de aprovação. Eles estão na página, não no payload.
Para um pipeline puramente XML, isso é uma lacuna. A conciliação de três vias precisa do PO, e o agendamento de pagamentos precisa da data de vencimento. O XML tem cac:OrderReference e cac:PaymentTerms, mas o fornecedor não é obrigado a preenchê-los em todas as notas. O design prático é uma coluna de origem por campo: impostos e identidade vindos do XML, contexto operacional vindo da página, e um estado explícito de "não presente" quando nenhum dos dois o tem.
Uma nota de crédito é um novo documento, não uma nota negativa
Uma nota de crédito usa o código de tipo de nota 381, carrega uma referência de cobrança à nota que corrige, declara um motivo e geralmente mantém seus valores positivos porque o tipo de documento carrega a direção. Registre-a como uma nota de compra negativa e o sinal pode ser invertido duas vezes: uma pelo tipo, outra pelo seu lançamento. O resultado é um crédito que aumenta o saldo.
Compense a nota contra a nota referenciada e verifique se a referência é resolvida. A diretriz da ZATCA permite que uma nota de crédito referencie várias notas originais como um intervalo de texto, então a referência nem sempre é uma chave única. Quando for um intervalo, divida o crédito ou retenha-o até que o fornecedor forneça um detalhamento por nota.
A tabela abaixo transforma os casos comuns em uma planilha de roteamento.
| Sintoma | Causa usual | Responsável |
|---|---|---|
| O total do XML difere do total impresso | Abatimento de linha ou pré-pagamento mapeado para o campo errado | Analista de contas a pagar, com o responsável pelo ERP para o mapeamento |
| O VAT do vendedor difere da tag 2 do QR | Anexo errado, renderização desatualizada ou erro de montagem do documento | Responsável pelo ERP ou pela integração |
| O VAT em SAR difere do razão | Total impresso convertido em vez do total de impostos em SAR do XML | Líder de impostos ou conformidade da Arábia Saudita |
| PO ou data de vencimento ausente | Campo apenas no PDF, ou ausente em ambos os registros | Analista de contas a pagar, depois o fornecedor |
| A nota de crédito não vai conciliar | A referência de cobrança é um intervalo ou aponta para uma nota substituída | Analista de contas a pagar, com o líder de impostos |
| O anexo não abre | O portal renderizou o PDF novamente, ou um problema de conformidade com PDF/A-3 | Responsável pelo ERP ou pela integração |
O Código QR É uma Verificação de Consistência, Não um Certificado de Liberação
Corresponder um QR à página prova que os dois foram construídos a partir dos mesmos valores; não prova que a fatura foi liberada. As tags 1 a 5 são os únicos valores comerciais no código. Não há número de fatura, nem item de linha, nem PO e nem número de VAT do comprador. Um QR é um resumo, e um resumo curto.
Usadas como verificação de entrada, as tags 1 a 5 ainda são úteis. Normalize antes de comparar: o número de VAT como dígitos, o timestamp como um instante, porque Arabia Standard Time e UTC podem descrever o mesmo momento, e os valores com duas casas decimais. Uma divergência geralmente significa que o QR pertence a uma fatura diferente, ou que a página foi reconstruída depois que o código foi gerado. Ambos os casos merecem uma pausa.
As tags 6 a 9 não podem ser verificadas a olho nu ou por um scanner de celular. Verificá-las exige o XML assinado, a forma exata em nível de byte sobre a qual a assinatura foi calculada, a cadeia de certificados e uma verificação de revogação. Um scan que exibe nove campos exibiu nove campos. Não verificou a assinatura.
As equipes de AP recebem informações diferentes sobre isso. No fórum de desenvolvedores do Fatoora, um profissional de AP escreveu: "A equipe de suporte da ZATCA diz que é obrigatório escanear os códigos QR das faturas de fornecedores. Estou fazendo minha pergunta da perspectiva de Contas a Pagar." A resposta do líder da comunidade foi que o escaneamento é uma verificação opcional, e que uma fatura que já foi reportada ou liberada com sucesso já atende aos requisitos de faturamento eletrônico. O mesmo tópico registra que o aplicativo da ZATCA não consegue escanear códigos fora da Arábia Saudita, o que é um problema prático para um centro de serviços compartilhados em outro país.
A posição viável: use o QR como um controle de amostragem e uma verificação da integridade do anexo. Não o torne uma barreira por fatura, e não trate um scan como evidência de liberação. A evidência é o XML liberado ou reportado, retido com sua resposta.
Um QR copiado pode estar em uma página manipulada. Compare os valores; não trate o quadrado como prova.
Um fluxo de trabalho em seis etapas que sobrevive às exceções
O fluxo de trabalho de contas a pagar de e-invoices sauditas precisa produzir uma linha por item da fatura, um rótulo de origem para cada campo e um estado de exceção que ninguém possa sobrescrever silenciosamente. As etapas são deliberadamente entediantes. O tédio é o que torna o resultado defensável seis anos depois.
Triagem do artefato
Inspecione a coleção de anexos antes de ler a página. Registre um dos quatro estados de origem: XML bruto, híbrido com XML acessível, híbrido com página somente de imagem, ou PDF simples ou digitalização. Gere o hash do original e guarde-o. O estado de origem determina como os próximos dois passos serão executados.
Extraia o cabeçalho uma vez
Número da fatura, UUID, código de tipo, data e hora de emissão, identificadores de VAT do vendedor e do comprador, moeda e moeda de imposto. Mantenha o UUID separado do número da fatura. Um identifica o documento no sistema da ZATCA, o outro o identifica nos livros do fornecedor, e as verificações de duplicidade precisam de ambos.
Expanda as linhas
Uma linha por cac:InvoiceLine: ID da linha, quantidade e unitCode, preço e BaseQuantity, AllowanceCharge, líquido declarado da linha, categoria e alíquota de VAT, imposto da linha. Não copie os totais do cabeçalho para cada linha sem rotular o grão, ou uma soma posterior contará o mesmo total uma vez por linha.
Compare um conjunto restrito
VAT do vendedor, timestamp, total incluindo VAT e total de VAT, entre XML, página e código QR. Depois execute quatro verificações aritméticas: a fórmula do líquido da linha, a soma das linhas contra LineExtensionAmount, TaxExclusiveAmount mais imposto contra TaxInclusiveAmount, e TaxInclusiveAmount menos pré-pago mais arredondamento contra PayableAmount.
Aplique os controles de AP separadamente
Cadastro do fornecedor, verificação de duplicidade sobre VAT do fornecedor mais número da fatura mais UUID, conciliação de PO e recebimento, recuperação de VAT, autoridade de aprovação. Uma fatura processada não é uma fatura aprovada. Mantenha os controles em seus próprios status para que uma falha de processamento não pareça uma rejeição comercial.
Arquive o original e o registro
Mantenha o XML ou contêiner PDF/A-3 intacto, a evidência de clearance ou reporte, o registro de extração e o histórico de exceções juntos. A planilha aponta para o artefato. Ela não o substitui, e não pode reproduzir uma assinatura.
Três responsáveis, três perguntas. O analista de contas a pagar é responsável pela conferência comercial e pela consulta ao fornecedor. O responsável pelo ERP ou pela integração é responsável pelo anexo, pelo namespace e pelo parser. O líder fiscal saudita é responsável pela categoria de VAT, pela evidência de liberação e pela decisão de retenção. Um único sinalizador "válido" junta essas respostas em uma só e esconde qual equipe precisa agir. Armazene os estados separadamente: analisado, falha de esquema, valores divergentes, evidência criptográfica não verificada, retenção em AP, aprovado para pagamento.
O que a Extração Visual Pode e Não Pode Fazer Aqui
Uma ferramenta de extração visual lê a página, não o anexo, então ela pertence ao lado do PDF deste fluxo de trabalho. Essa é a parte que o ImageToTable.ai cobre, e é um papel mais restrito do que "extração de fatura ZATCA". Ainda assim, é útil em três situações.
A primeira é o campo que existe apenas no PDF. Quando o ERP analisa o XML, a página ainda pode ser o único lugar onde o número da PO, a nota de entrega ou a aprovação interna aparece. Custom Column Extraction permite digitar os nomes das colunas que você quer, como "PO Number", "Payment Due Date" e "Delivery Note", e o modelo encontra os valores pelo significado, não por coordenadas fixas. Os nomes das colunas que você insere se tornam os cabeçalhos da tabela de saída.
A segunda é a exceção sem XML. Quando um fornecedor envia um PDF comum ou um PDF/A-3 apenas com imagem, não há nada para analisar. A página se torna a fonte. O processamento em lote lida com uma pasta de layouts de fornecedores variados em uma única passagem e mescla as linhas em uma planilha, que é a diferença entre uma fila de exceções viável e uma pilha de conversões avulsas.
A terceira é a comparação visual. O Review Mode com destaque de Bbox permite passar o mouse sobre uma célula e ver a região na página original que a produziu, e clicar em uma região para voltar à célula. Para uma fatura ZATCA, é assim que um analista compara o valor a pagar impresso com o valor do XML sem imprimir a página e usar uma régua. O valor original da IA é mantido e pode ser restaurado se uma edição estiver errada. Para digitalizações apenas com imagem e layouts bilíngues densos, um Model Tier mais alto usa um modelo de visão mais forte. O padrão cobre a maioria das tabelas impressas; o caso difícil é uma impressão digitalizada com texto árabe pequeno e um carimbo sobre o total.
Os limites importam na mesma medida. Ele não abre o XML incorporado, não valida o selo criptográfico, não verifica o hash do código QR, não integra um fornecedor à ZATCA nem arquiva nada. Uma extração visual de um PDF/A-3 é uma observação da página renderizada, não uma análise do payload assinado. Rotule assim na saída. Se a página omite uma linha de abatimento, a observação também vai omiti-la, e a verificação aritmética do passo 4 é o que detecta a diferença.
A mesma distinção se aplica a outros mercados. O sistema de faturas qualificadas do Japão não tem payload XML obrigatório, então a camada visual costuma ser a única fonte, e é por isso que a mesma disciplina se aplica a faturas qualificadas japonesas. O mandato da Alemanha faz do arquivo estruturado a fatura, o que muda a ordem de entrada para faturas de fornecedores alemães. Uma equipe que lida com ambos precisa de um mapa de campos e duas regras de entrada.
O Arquivo Faz Parte da Extração
A planilha não é a fatura, e um PDF sozinho não é o registro que um auditor pode validar. O Article 66 do Regulamento de Implementação do VAT da Arábia Saudita exige que faturas, livros, registros e documentos contábeis sejam mantidos por pelo menos seis anos a partir do fim do período fiscal a que se referem. Os registros de ativos de capital duram o período de ajuste do Article 52 mais cinco anos, o que equivale a 11 anos para ativos móveis e 15 para imóveis. Os registros devem estar em árabe e armazenados no Reino, eletronicamente ou fisicamente, com acesso a partir de um terminal no Reino.
Mantenha o XML recebido, ou o contêiner PDF/A-3 intacto, em vez de apenas uma cópia extraída do anexo. Mantenha a resposta de clearance ou de reporte das faturas padrão, porque essa é a evidência de que a fatura foi aceita. Mantenha o contador de faturas e a cadeia de hash anterior intactos; uma lacuna já é evidência por si só. Mantenha as notas de crédito junto com as faturas que elas corrigem, já que a alteração é proibida.
O registro de extração tem seus próprios campos: hash do arquivo de origem, tipo de origem, versão do parser ou do modelo, versão do conjunto de regras, origem no nível do campo, valor normalizado, valor bruto e estado de exceção. Reprocessar um parser ou um modelo depois exige os mesmos bytes. Se você sobrescrever o original com um valor normalizado, terá destruído a evidência de que precisaria para defender a linha.
Outros modelos de clearance defendem o mesmo ponto. O sistema KSeF da Polônia atribui um identificador sem o qual a fatura não existe legalmente, e as faturas CFDI do México combinam um arquivo estruturado com uma representação imprimível. Em cada caso, o arquivo é o artefato estruturado mais a resposta da autoridade, não o PDF.
Perguntas Frequentes
Posso extrair itens de linha de um código QR da ZATCA?
Não. As tags 1 a 5 contêm o nome do vendedor, o número de VAT do vendedor, o carimbo de data e hora, o total com VAT incluído e o total de VAT. Não há número da fatura, identificador do comprador nem detalhe de linha. Use o código para conferir esses cinco valores, não para montar uma tabela de itens de linha.
Toda fatura PDF/A-3 é híbrida, com XML dentro?
Não. O PDF/A-3 é um contêiner que permite arquivos incorporados; ele não garante que o fornecedor colocou um ali, que o anexo é legível ou que a página foi gerada a partir dele. Abra a coleção de anexos e faça o parse do arquivo antes de tratar o PDF como fonte estruturada.
Qual total devo lançar quando uma fatura inclui um pré-pagamento?
Lance o valor da fatura a partir de TaxInclusiveAmount e pague o valor devido a partir de PayableAmount. Mantenha PrepaidAmount em sua própria coluna e vincule-o à fatura de pré-pagamento. Não junte os três em um único campo "total" e não sobrescreva o valor da fatura com o valor a pagar.
O PDF/A-3 é a fatura legal?
Não. O XML assinado é a fatura. O PDF/A-3 é a cópia legível por humanos que tem permissão para carregá-lo. Para uma fatura padrão, guarde o XML liberado ou o híbrido liberado, e arquive o contêiner em vez de um PDF salvo novamente.
Posso usar OCR em uma fatura da ZATCA?
Sim, quando não há XML utilizável. Um PDF somente de imagem, uma digitalização ou uma foto podem ser lidos visualmente, mas o resultado é uma observação da página, não um parse do payload assinado. Registre o método, execute as mesmas verificações de normalização e aritmética, e confira os cinco valores do código QR onde forem legíveis.
Como lidar com uma nota de crédito que referencia várias faturas?
Trate-a como um novo documento com tipo 381 e uma referência de cobrança, não como uma fatura de compra negativa. Se a referência for um intervalo, divida o crédito entre as faturas originais ou retenha-o até que o fornecedor forneça um detalhamento por fatura. Compense-o com as faturas que ele corrige e mantenha-o arquivado junto com elas.
O ImageToTable.ai analisa o XML UBL incorporado ou verifica o código QR?
Não. Ele lê a página do PDF, a imagem ou o scan e extrai as colunas que você define, incluindo campos que existem apenas na página impressa. Ele não abre o anexo XML incorporado, não valida o carimbo criptográfico, não verifica o hash do código QR, não integra um fornecedor à ZATCA nem envia uma declaração. A análise do XML e a verificação de assinatura pertencem ao seu ERP ou à sua camada de integração.
Por quanto tempo uma fatura de fornecedor saudita deve ser guardada?
No mínimo seis anos a partir do fim do período fiscal ao qual se refere, conforme o Article 66 do Regulamento de Implementação do VAT. Os registros de ativos de capital duram o período de ajuste mais cinco anos, ou seja, 11 anos para ativos móveis e 15 para imóveis. Guarde o XML ou o contêiner PDF/A-3 intacto, a evidência de clearance ou de reporte e as notas de crédito juntos.
A Linha Que Sobrevive à Pergunta
A fatura que sobrevive a uma auditoria é aquela em que cada linha consegue nomear o campo de onde veio, o artefato por trás dele e a verificação que a deixou passar. Quando esse mapa existe, a divergência entre o PDF e o XML deixa de ser um mistério e se torna uma fila com um responsável.