Fonctionnalités
Classées par impact, pas par ordre alphabétique — de la vérification sur cinq couches au kit de données à votre nom. Chaque fonction avec la situation qu’elle sauve. Tout en bas : ce que proposent les autres, avec les sources.
Schéma XML, EN 16931, le format (XRechnung, ZUGFeRD / Factur-X, Peppol BIS 3), la CIUS nationale et le conteneur PDF/A-3. 1 784 contrôles à chaque passage, dont 1 749 issus des jeux de règles officiels.
Cas d’usageUne facture arrive par e-mail. Deux secondes plus tard, vous savez si vous pouvez la comptabiliser ou devez la refuser — avec le numéro de règle et le champ concerné.
Confronté au validateur officiel KoSIT 1.6.2 et au banc d’essai européen : 352 échantillons, 0 écart. Démontré dans notre CI et redémontré à chaque mise à jour des règles.
Cas d’usageLe fournisseur affirme « mon fichier est valide ». Vous lui montrez le verdict que rendra l’administration — trois semaines avant qu’elle ne le rende.
Erreurs, avertissements et signalements sont distingués, y compris « serait une erreur dans la version actuelle ». Chaque résultat indique le jeu de règles sous lequel il a été produit et peut être rejoué contre un autre.
Cas d’usageLa facture était valide en janvier et ne l’est plus. La machine à remonter le temps montre quelle version des règles a changé cela — la base de la discussion avec le fournisseur.
Non pas « cette facture est-elle valide » mais « ce destinataire l’acceptera-t-il » : choisissez le profil cible, vérifiez contre ses règles. Y compris le Leitweg-ID et sa clé de contrôle, que les jeux de règles standard ne vérifient pas.
Cas d’usagePremière facture à une administration. Le contrôle préalable vous dit avant l’envoi si elle passera — au lieu de la lettre de rejet trois semaines plus tard.
Chaque résultat porte un niveau de risque d’acceptation plutôt qu’un simple valide/invalide. Et le montant de TVA déductible qui dépend du document est affiché en chiffres à côté.
Cas d’usageAu lieu de « trois avertissements », la comptabilité lit : 4 560 € de TVA déductible dépendent de cette facture. C’est ce qui décide si quelqu’un décroche le téléphone.
Un jeu de règles déclaratif par-dessus : champs obligatoires, valeurs autorisées, vos propres limites — vérifiés dans la même sortie que les règles officielles, sans toucher aux jeux de règles.
Cas d’usageLa politique du groupe exige un numéro de commande sur chaque facture entrante. Sans lui, la facture est valide au sens de l’EN 16931 — et reste un constat chez vous.
Une facture électronique peut transporter des fichiers. Nous vérifions ce qu’aucun jeu de règles officiel ne vérifie : noms de fichiers trompeurs, noms contenant un chemin, références qui ne sont ni web ni mail. Aucune référence externe n’est récupérée.
Cas d’usageLa facture transporte un « justificatif.pdf » qui est en réalité autre chose. C’est dans le résultat avant que quiconque ne clique.
Un PDF ZUGFeRD a deux visages : la page imprimée et le XML qu’il contient. Nous rapprochons les ancres coûteuses — total (BT-112), IBAN de paiement (BT-84), numéro de facture (BT-1). Un validateur purement XML ne voit jamais cet écart.
Cas d’usageLa page affiche le bon IBAN, le XML celui d’un inconnu. La comptabilisation et le paiement suivent le XML. C’est là que cela se voit, avant que l’argent ne parte.
Le rapprochement simple peut être déjoué : encre blanche, corps 0,0001, transparence totale, texte placé hors page, rogné, recouvert, glyphes sans largeur, mode de rendu invisible. Huit mécanismes — tous détectés. Dissimuler n’a aucune explication innocente : c’est le signal de fraude le plus fort de toute la fonction.
Cas d’usageLe total honnête est écrit en blanc sur blanc pour que le validateur le trouve et se taise. La page qu’ouvre votre comptable dit autre chose. Nous signalons la cachette, pas la concordance.
Une police incorporée peut déclarer que le glyphe dessiné correspond à un autre caractère que celui extrait. C’est l’attaque la plus fine : un verdict propre sur un document dont le total visible est faux. Nous décodons honnêtement — ce qui est dessiné fait foi.
Cas d’usageLa page affiche 9 999,00 €, le XML dit 999,00 €, et la police fait lire 999,00 € au contrôle. Ce cas précis est figé sous forme d’échantillon de test.
Un PDF peut porter deux charges ZUGFeRD correctement nommées avec des totaux et des IBAN différents ; c’est le système destinataire qui tranche. C’est signalé. S’y ajoute la vérification complète du conteneur PDF/A-3. 22 échantillons d’attaque sont versés au dépôt, dont 4 documents honnêtes qui doivent rester propres — si une défense cesse d’agir, la compilation échoue.
Cas d’usageDeux systèmes lisent le même fichier et comptabilisent des montants différents. Sans ce constat, personne ne le remarque avant la relance.
Ce qui peut être corrigé sans risque l’est : corrections structurelles et normalisations sans perte de valeur — espaces, échappement, format de date, ordre des éléments. Un troisième anneau propose et attend votre confirmation. Il ne touche jamais aux montants, aux taux ni à l’IBAN. Avec un diff avant/après.
Cas d’usageL’ERP exporte 40 factures avec les éléments dans le mauvais ordre. Une exécution, 40 fichiers valides, chaque original intact à côté.
Corrigez n’importe quel champ directement dans le XML, avec numéros de ligne et coloration syntaxique, revalidation immédiate — puis téléchargez le fichier corrigé ou le PDF ZUGFeRD réparé.
Cas d’usageUne faute de frappe dans le numéro fiscal bloque le paiement. Vingt secondes au lieu d’un ticket chez l’éditeur.
Cliquez sur un constat et le champ concerné s’allume dans la vue lisible de la facture — grâce aux identifiants BT/BG que la règle cite déjà. Sans lire de XPath.
Cas d’usageC’est la collègue de la comptabilité qui doit corriger, pas l’informatique. Elle voit de quelle case il s’agit.
Chaque règle de validation expliquée et liée depuis chaque résultat, avec les chemins UBL et CII côte à côte. Quand les totaux ne tombent pas juste, nous nommons le montant, ce que donnent les autres chiffres, et l’écart — en allemand, anglais et français.
Cas d’usageAu lieu de « BR-DE-15 non respectée », vous lisez quel champ manque, pourquoi il est obligatoire et ce qu’il doit contenir.
« Ma facture a été refusée — qui a raison ? » Collez le fichier et le motif invoqué, et vous obtenez si la facture enfreint réellement une règle ou si le système destinataire est plus strict que la norme.
Cas d’usageLe client refuse, vous êtes sûr que le fichier est bon. Au lieu d’un échange d’e-mails, une référence de règle est sur la table.
Parcours guidé ou formulaire complet, tous deux avec l’indication de validité pendant la saisie. Franchise en base, conditions de paiement, BIC, référence de commande, textes libres, pièces jointes — sortie en XRechnung (UBL ou CII), PDF ZUGFeRD ou Peppol BIS 3.
Cas d’usageLe premier client exige désormais une facture électronique. Aucun logiciel à acheter, aucune formation : remplir le formulaire, télécharger un fichier valide.
Une facture envoyée ne se modifie pas, elle s’annule. Un clic l’ouvre en avoir (381) ou en facture rectificative (384), reprend toutes les données et inscrit la référence à l’original (BT-25).
Cas d’usageMauvais montant, facture déjà partie. La voie propre prend un clic au lieu d’une question au conseil fiscal.
Au-delà de XRechnung et Peppol, les déclinaisons nationales : Pays-Bas (NLCIUS), Roumanie (CIUS-RO / e-Factura), Croatie (HR-CIUS), Portugal (CIUS-PT), ainsi que la France et la Belgique avec les préréglages et identifiants adaptés — les SIREN/SIRET sont vérifiés par leur clé de contrôle.
Cas d’usageLe premier client français. Pas de second logiciel, pas de second fournisseur : la même interface, le bon jeu de règles.
Factures et modèles enregistrés, fiches clients, factures récurrentes mensuelles/trimestrielles/annuelles qui font avancer le numéro et la période. Sur le PDF : votre logo, votre couleur d’accent, un QR de paiement et une note.
Cas d’usageDouze loyers identiques dans l’année. Créés une fois, confirmés onze fois — et le document a l’air de venir de votre entreprise, pas d’un outil.
CSV, XLSX ou ODS en source : les colonnes sont pointées vers des champs au lieu de devoir en porter le nom, un essai à blanc liste chaque facture avec son numéro et son montant avant que rien n’existe — et chaque numéro attribué est consigné localement pour ne pas l’être deux fois.
Cas d’usageLe premier du mois, 300 factures issues de l’export du suivi des temps. D’abord l’essai à blanc, puis 300 fichiers valides.
UBL ↔ CII ↔ PDF ZUGFeRD, en local, avec une nouvelle vérification après chaque conversion. Et une facture vérifiée peut être incorporée dans votre propre PDF.
Cas d’usageLe destinataire n’accepte que le CII, votre logiciel ne produit que de l’UBL. Deux clics au lieu d’un projet ERP — et le fichier n’a jamais été sur le serveur d’un tiers.
Un PDF ZUGFeRD est traité pour ce qu’il est : la page imprimée et le XML incorporé ensemble, lisibles côte à côte en résumé ou en détail complet — au lieu d’extraire le XML et d’oublier la page.
Cas d’usageLa facture entrante doit être vérifiée et lue par un humain en même temps. Les deux dans la même vue, sans second logiciel.
Une couche de texte positionnée plutôt que des suppositions, des modèles par émetteur, et pour chaque champ un indice de fiabilité avec sa provenance. Les champs les moins sûrs passent en premier à la relecture. Un résultat n’est jamais présenté comme certain s’il ne l’est pas.
Cas d’usageLe fournisseur continue d’envoyer des PDF. Au lieu de retaper, vous les lisez, confirmez les trois champs incertains et obtenez une facture structurée.
Les factures scannées sans couche de texte sont redressées, binarisées et reconnues dans le navigateur — le moteur n’est chargé qu’en cas de besoin. Rien ne part vers un service de reconnaissance.
Cas d’usageLe document scanné du classeur de 2019 doit entrer dans le système. Il ne sort pas de la maison pour autant.
Bon de livraison, tableur, contrat, e-mail : le lecteur prend seize formats, décide d’après les octets et jamais d’après l’extension, conserve le type de chaque cellule et travaille avec un budget fixe — le fichier d’un inconnu n’obtient pas un temps de calcul illimité.
Cas d’usageLa facture s’accompagne d’un relevé d’heures en tableur. Il est lu et affiché sans ouvrir de suite bureautique et sans risque de macro.
Une facture peut être valide au sens de l’EN 16931 et rester incomplète du point de vue de la TVA. Un contrôle de contenu distinct parcourt les mentions obligatoires — à titre indicatif, jamais un refus.
Cas d’usageLa facture est techniquement valide mais la mention d’autoliquidation manque. Cela coûte la déduction plus tard, pas l’acceptation aujourd’hui.
Les numéros d’identification à la TVA de quatorze États membres sont vérifiés par leur clé de contrôle. S’y ajoutent cinq schémas à risque, dont la livraison intracommunautaire fictive.
Cas d’usageLe nouveau fournisseur d’un autre pays de l’UE facture sans taxe. Le numéro est-il seulement formellement correct ? La réponse arrive avant le paiement.
Lieu de la prestation, exonération, taux et redevable sont déterminés de façon déterministe — avec la disposition dont découle la décision. Là où les données ne suffisent pas, l’outil s’abstient explicitement au lieu de deviner.
Cas d’usagePrestation de conseil pour un client en Belgique. Qui est redevable ? La réponse est là, avec la référence à côté.
Des dossiers entiers sur le web, le bureau et le terminal, des chiffres clés plutôt qu’une liste de fichiers, un rapport en PDF et CSV — au besoin à l’en-tête du cabinet. La réparation et la conversion s’exécutent aussi par lots.
Cas d’usage800 pièces entrantes d’un client passent pendant la nuit. Au matin, la liste des douze à refuser.
Non pas « ce fichier est-il valide » mais « qu’y a-t-il ici » : ce qui est vraiment une facture électronique, ce qui n’est qu’un PDF sans structure, qui envoie encore la mauvaise chose — classé selon la classification officielle.
Cas d’usageNouveau client, un dossier de 2 000 pièces. Après une exécution, vous savez quels fournisseurs contacter.
Une ligne ajoutée par document vérifié, jamais réécrite — la preuve que la vérification a eu lieu, quand, et face à quoi. Lisible dans l’application, pas seulement sous forme de fichier.
Cas d’usageLe contrôle fiscal demande comment les entrées ont été contrôlées. Le journal est la réponse, pas une description de la procédure.
Un projet du chapitre facture électronique de la documentation de procédure, sur papier à en-tête. Plus un fonds scellé où chaque entrée est chaînée à la précédente : modifiez un document, un champ ou l’ordre, et la racine change — une seule valeur à noter. Livré en dossier par client.
Cas d’usageLe cabinet doit documenter et prouver. Les deux sortent des mêmes données, en une soirée plutôt qu’en un projet.
Toutes les autres commandes jugent un document ; celle-ci juge les fiches partenaires derrière : qui n’a pas d’adresse électronique, quel numéro de TVA est invalide, qui est saisi deux fois. Depuis un export ERP, depuis les factures existantes — ou les deux, ce qui révèle aussi les contradictions.
Cas d’usageSavoir avant la bascule lesquels de vos 900 fournisseurs feront échouer les factures. Après, c’est plus cher.
260 factures valides et 135 volontairement défectueuses en quatorze groupes — chaque catégorie de TVA, chaque type de document, huit devises, six pays, pièces jointes, remises, scénarios PDF. Le manifeste indique la version du kit, une empreinte de contenu, la date de génération et chaque jeu de règles épinglé : personne ne peut se voir dire qu’il a été testé sur un kit plus récent que le sien.
Cas d’usageL’éditeur d’ERP veut savoir si son contrôle des entrées tient la route. Il passe 395 fichiers et compare au verdict livré — fichier par fichier.
Pour chaque échantillon défectueux généré, l’original corrigé est livré à côté — exactement l’état d’avant le défaut injecté. Un diff entre les deux montre précisément ce défaut, et rien d’autre.
Cas d’usageLe test échoue et personne ne sait pourquoi. Le diff avec l’échantillon de référence répond en une ligne.
L’assistant insère vos parties, lignes, coordonnées bancaires et textes libres dans le kit et le construit dans le navigateur — 395 échantillons rendus, vérifiés et compressés, sans téléversement. Il montre à l’avance combien d’échantillons chaque saisie touche (mesuré, pas déclaré) et interrompt la construction si un verdict devait basculer. Au besoin avec un filigrane sur chaque page. La même exécution existe en commande, pour qu’un kit construit dans un onglet et un kit construit en CI soient le même artefact.
Cas d’usageL’éditeur envoie à ses clients des factures de test portant les vraies données du client — au lieu de « Société Exemple », qui ne ressemble à rien de ce qu’un import rencontrera.
Un rapport A4 daté sur ce qu’une solution a testé et ce qu’elle a trouvé : détecté, manqué, accepté à tort, fausse alerte, aucun verdict. S’abstenir de répondre ne donne pas un meilleur score. Avec la version du kit, l’empreinte de contenu et chaque version de règles — même entrée, même rapport. Au besoin au nom et au logo du partenaire.
Cas d’usageLe cabinet présente à son client, noir sur blanc, ce contre quoi son logiciel a été testé — sur son propre papier à en-tête, avec une date.
Vérifier, réparer, générer, convertir, extraire, faire l’état des lieux, journaliser, sceller, construire un kit, écrire un rapport — le tout sans compte et sans réseau. Code de sortie 0 ou 1, sortie en JSON si vous le souhaitez.
Cas d’usageLa facture est produite dans la chaîne de build. Un document invalide fait passer le pipeline au rouge avant que quiconque ne le reçoive.
Onze outils — vérifier, rapport, extraire le XML, réparer, plan de réparation, risque fiscal, convertir, lire depuis un PDF, générer, lire un document, expliquer une règle. En local, sans clé d’API, constats en JSON avec un plan de réparation.
Cas d’usageL’agent écrit la facture ; Beleggo refuse de la laisser passer si elle est invalide. Un modèle probabiliste reçoit un garde-fou déterministe.
Un autre système dépose des fichiers dans un dossier et les verdicts reviennent à côté. Ou il interroge en HTTP — à une adresse que seule cette machine atteint.
Cas d’usageL’ancien ERP ne sait pas intégrer de bibliothèque, mais il sait écrire des fichiers. Cela suffit à le raccorder.
Un paquet de transfert de pièces ou un vrai lot d’écritures pour DATEV ; les numéros de conseil et de client sont demandés, jamais devinés, et le lot reste non validé. Pour Peppol, l’enveloppe prête avec son manifeste — Beleggo n’est pas un Access Point et ne transmet rien.
Cas d’usageLes pièces vérifiées doivent rejoindre le logiciel du cabinet et le prestataire. Deux commandes, pas de presse-papiers.
La vérification s’exécute dans votre navigateur ou sur votre machine. Aucun serveur ne reçoit de document, aucun compte ne les héberge. Ouvrez l’onglet réseau ou débranchez le câble — cela continue de fonctionner.
Cas d’usageLe cabinet vérifie les pièces de ses clients sans contrat de sous-traitance et sans question de secret professionnel : les pièces ne sortent jamais, parce qu’il n’y a pas de tiers.
Ce qui reste dans le navigateur reste chiffré : une clé détenue par l’appareil, des enregistrements chiffrés et une chaîne qui rend toute altération visible. Sauvegarde protégée par phrase secrète. Dit franchement : la clé est sur le même appareil que les données — contre un portable perdu, c’est le chiffrement du disque qui protège, pas nous.
Cas d’usageDes brouillons et des résultats de vérification sont sur le poste du cabinet. Ils ne sont pas lisibles en clair, et une modification ultérieure se voit.
Une vraie facture devient un échantillon transmissible sans risque : les identités sont remplacées par des identités inventées de même forme, de sorte que la validité et le comportement des règles subsistent. Les dates se décalent toutes du même écart, les montants sont masqués.
Cas d’usageLa facture problématique doit parvenir à l’éditeur — sans livrer le nom du client, les coordonnées bancaires ni les montants.
Application de bureau pour Windows, macOS et Linux, et PWA installable dans le navigateur. Pas de runtime Java, pas de Docker, rien que quelqu’un doive faire tourner et maintenir à jour.
Cas d’usageChez un client sans Wi-Fi, en avion, dans un réseau administratif isolé : la vérification s’exécute quand même, avec le même verdict.
Un rapport de défaut s’écrit sous forme de paquet sur votre propre disque : les étapes précédentes, l’environnement, aucune capture d’écran et aucune donnée de facture. Qui le reçoit peut rejouer la séquence.
Cas d’usageQuelque chose se passe mal sur une facture client. Le rapport décrit la séquence, pas le client.
Pour aller plus loinParcourir la bibliothèque d’erreursTélécharger des factures de testObtenir l’application de bureau
Sous votre marque
Beleggo se réétiquette entièrement aux couleurs du cabinet — l’application, les rapports, les données de test. Ce qui en sort ne reste pas sur votre bureau : c’est une offre à vos clients qu’un cabinet sans serveur ne pourrait pas faire autrement.
Une application au nom du cabinet
Nom, sous-titre, ligne d’en-tête, logo, couleur d’accent et fond de page viennent de la configuration, pas d’un ticket. Le message permanent au-dessus de chaque vue est lui aussi la formulation du cabinet — par vue et par langue.
Deux formats, le même moteur
L’application complète — vérifier, facture lisible, liste des constats, chronologie des jeux de règles, sélecteur de règles, exports, création. Ou la version minimale : déposez un fichier, VALIDE ou INVALIDE, rien d’autre. Les deux sont construites séparément et peuvent être livrées côte à côte.
Aucune infrastructure
Un dossier de fichiers sur l’hébergement dont vous disposez déjà, y compris sous un sous-chemin du site du cabinet. Pas de serveur, pas de base de données, pas de Java, rien que quelqu’un doive exploiter, sauvegarder et maintenir à jour.
Des rapports à en-tête
Le rapport de vérification en PDF et CSV, le rapport de préparation, le projet de documentation de procédure et le dossier par client portent le logo et la couleur du cabinet. L’en-tête est une configuration et vit hors du programme — il s’entretient, il ne se recompile pas.
Des données de test au nom du cabinet
Le kit de données peut être généré avec les informations du cabinet — ou celles d’un client. Le rapport de préparation et la page de comparaison portent le nom, l’adresse et le logo du partenaire.
« Vérifiez votre facture sur notre site. »
Le client dépose son fichier dans l’application du cabinet et obtient immédiatement un verdict — sans compte, sans téléversement, et sans que le cabinet voie jamais la pièce. Le fichier reste sur la machine du client. C’est exactement l’offre qu’un concurrent avec téléversement serveur ne peut pas faire.
Le client crée lui-même une facture valide
Pour tous ceux qui n’ont pas d’ERP et n’en achèteront pas : remplir le formulaire, télécharger une XRechnung ou un PDF ZUGFeRD valide, avec la validité affichée pendant la saisie. Le client évite l’achat d’un logiciel, le cabinet évite l’appel.
Une trace datée par client
Ce que le logiciel d’un client a vérifié et ce qu’il a trouvé : détecté, manqué, accepté à tort, fausse alerte, aucun verdict. À l’en-tête du cabinet, avec la date, la version du kit, l’empreinte de contenu et chaque version de règles — même entrée, même rapport.
Des factures de test qui ressemblent aux siennes
Au lieu de « Société Exemple », un kit portant les vraies données du client. Il teste son propre traitement des entrées sur des pièces qui ressemblent à son trafic réel — et non sur des exemples que tout import reconnaît comme tels.
Tout le dossier de pièces, passé en revue une fois
Un état des lieux et une exécution par lots sur l’ensemble des entrées d’un client : ce qui est vraiment une facture électronique, ce qui n’est qu’un PDF sans structure, quels fournisseurs envoient encore la mauvaise chose, quelles pièces refuser. Une prestation dont le résultat se facture.
La documentation de procédure dont il a besoin de toute façon
Le chapitre facture électronique en projet, à l’en-tête du cabinet, avec le journal de vérification et le fonds scellé qui prouvent que la vérification a eu lieu. Deux prestations facturables issues des mêmes données, en une soirée plutôt qu’en un projet.
Et la question à laquelle personne d’autre ne répond proprement
Aucun contrat de sous-traitance, aucune question de secret professionnel — parce qu’il n’y a pas de tiers à qui quoi que ce soit serait divulgué. Les pièces du client n’atteignent personne : ni nous, ni même le cabinet lorsque le client vérifie lui-même.
Le réétiquetage et la distribution nécessitent une licence OEM ; la modification et la prévisualisation, non. Le format se discute, il ne se choisit pas dans un panier — et Beleggo n’est pas un Access Point et ne transmet rien, et un logiciel ne peut pas être certifié GoBD.
Face à face
Cinq fournisseurs nommés, uniquement des informations publiées sur leurs propres pages, chaque ligne avec sa source. À gauche, ce qu’ils publient. À droite, ce que Beleggo propose.
Autres fournisseurs
Beleggo
Rien n’est téléversé — en local dans le navigateur/l’application de bureau
Autres fournisseurs
Beleggo
Illimité (web + bureau)
Le tableau complet, avec date et source par cellule →
Toutes les données relatives aux tiers proviennent de leurs propres pages publiques (voir la colonne de date) et peuvent changer. Aucun jugement, seulement des faits.
Une donnée obsolète ou erronée ? Signalez-le-nous — nous corrigeons rapidement.
Sans compte, sans téléversement, sans limite quotidienne. Si une information de cette page est inexacte, dites-le-nous — nous la corrigeons.
Commencer