`CHECK-KSEF-NUMBER-MISSING`

InvoiceIn checks · règle de validation

InvoiceIn checksInformation

Ce document est une facture structurée polonaise (KSeF FA(2)/FA(3)), mais aucun numéro KSeF ne l'accompagnait. Ce numéro de 35 caractères est attribué par KSeF au moment où il accepte la facture ; il ne figure donc jamais dans le XML : le client KSeF du destinataire le reçoit à côté de la facture — dans la réponse de l'API, dans l'UPO ou dans le QR code de la visualisation. À partir du 1er janvier 2027, l'art. 108g de la loi polonaise sur la TVA impose à l'assujetti actif qui paie une facture structurée émise par un autre assujetti actif — par virement ou par tout instrument de paiement portant un libellé — d'indiquer ce numéro dans le libellé du paiement, ou un identifiant collectif (NNNNNNNNNN-IZRRRRMM-…), que l'une ou l'autre partie peut générer, lorsqu'un seul paiement règle deux factures ou plus. Transmettez-le via ?ksef=… ou l'en-tête X-KSeF-Number : il est vérifié par rapport à la facture et renvoyé dans payment.ksef_number, prêt pour la remise de paiement. La facture elle-même n'a aucun défaut — ceci est une note pour le côté receveur.

Champ: payment.ksef_number (PL national, not an EN 16931 term)
Jeu de règles: InvoiceIn checks
Qui doit corriger: Le destinataire

Cela concerne le côté destinataire : le document lui-même est correct, mais il manque quelque chose à la remise de paiement ou une donnée ne concorde pas — cela se corrige dans votre propre intégration, pas auprès du fournisseur.

Vérifiez votre propre facture

Déposez le fichier qui a échoué. Nous l'analysons, appliquons les jeux de règles officiels et listons chaque anomalie avec sa correction — 20 factures par jour, sans clé, rien n'est conservé.

Ouvrir la démo

La même explication via l'API: GET /v1/rules/CHECK-KSEF-NUMBER-MISSING?lang=fr