80 factures allemandes, un seul tableur
Comment traiter des Rechnung par lots sans saisie manuelle
Le goulot d'étranglement en comptabilité fournisseurs allemande n'est pas l'extraction d'une seule Rechnung. N'importe quel outil OCR décent peut récupérer un numéro de facture et un total sur un PDF propre. Le vrai problème survient quand vous extrayez les 80 — et découvrez que la Rechnung n°12 de l'électricien local applique une TVA à 7% sur la main-d'œuvre mais 19% sur les matériaux sur la même ligne, que la Rechnung n°37 de Metro applique un escompte Skonto de 4% caché dans le pied de page, et que le tableur fusionné produit par votre outil n'a aucune colonne pour indiquer quelle facture a fourni quelle ligne. Extraire une Rechnung prend 3 minutes. Vérifier et corriger les 80 prend tout un après-midi.
Quand 80 factures arrivent — pourquoi le traitement par lot n'est pas « 80 × une facture unique »
Traiter une facture à la fois fonctionne… jusqu'à un certain point. Pour la plupart des entreprises allemandes, le seuil critique se situe entre 30 et 50 factures fournisseurs par mois — le moment où l'écart entre « je peux gérer ça vendredi après-midi » et « ce truc me bouffe mon week-end » se creuse. À 80 factures, le problème n'est pas la vitesse de saisie par facture. C'est que les flux de travail unitaires introduisent quatre problèmes structurels que le traitement par lot hérite et amplifie :
Dérive des formats. Lorsque vous traitez les factures une par une et saisissez manuellement les données dans Lexware ou sevDesk, votre cerveau compense les différences de mise en page — vous voyez « Rechnungs-Nr. » sur une facture Metro et « Rechnungsnummer » sur une facture Transgourmet et vous savez qu'il s'agit du même champ. Une extraction automatisée par lot n'a pas cette intuition, à moins que vous ne lui ayez appris quoi chercher — non pas par position dans un modèle, mais par sens sémantique. Huit fournisseurs, huit mises en page, et un résultat de lot qui les mélange tous dans un seul tableur.
Fragmentation de la TVA. Les factures fournisseurs allemandes n'utilisent pas uniformément un seul taux de TVA. Dans un lot de 80 factures de fournisseurs du secteur hôtelier, jusqu'à quatre régimes de TVA apparaissent : 19 % standard (équipement, nettoyage), 7 % réduit (alimentation, livres), §13b autoliquidation (travaux de sous-traitance) et §19 Kleinunternehmer (aucune TVA). Une simple colonne « Taxe » qui capture un chiffre sur chaque facture est inutile — car ce chiffre a une signification différente sur chaque ligne, et votre calcul de déduction de TVA en amont nécessite de les séparer par type. Les champs obligatoires selon §14 UStG sur chaque facture déterminent ce qui doit être extrait — mais le traitement par lot ajoute la couche de maintenir cette extraction sémantiquement cohérente sur les 80 lignes.
Propagation des erreurs. Lorsque vous saisissez 80 factures manuellement, chaque opération est indépendante — une faute de frappe sur la facture n°44 ne se répercute pas sur la n°45. Dans une extraction par lot, si l'IA identifie mal le nom du fournisseur sur une facture parce que l'emplacement du logo a changé, vous ne le saurez qu'en vérifiant l'ensemble des résultats. Et si le mappage des colonnes est erroné — par exemple, la colonne Leistungsdatum a capturé le Rechnungsdatum chez un fournisseur qui formate les dates différemment — vous devez vérifier chaque ligne, pas seulement celle que vous avez remarquée.
Manque de traçabilité. Un tableur fusionné de 80 lignes doit vous indiquer quelle ligne provient de quel fichier. Si vous devez revenir à une facture originale pour vérifier un numéro de TVA intracommunautaire ou contrôler une ligne de remise, vous avez besoin d'un mappage fiable entre nom de fichier et ligne. Les outils de traitement par lot qui génèrent un CSV sans colonne source transforment l'audit en chasse au trésor dans votre dossier Téléchargements.
Aucun de ces problèmes n'existe lorsque vous traitez trois factures. À 80, les quatre sont actifs simultanément — et les résoudre est ce qui distingue un véritable flux de traitement par lot d'une « extraction unique, répétée 80 fois ».
Le problème des formats fournisseurs — un tableur, huit mises en page différentes
Une facture Metro et une facture Transgourmet partagent la même structure légale selon le §14 UStG, mais ne se ressemblent en rien. Metro place le numéro de facture dans le bloc en haut à droite, Transgourmet dans un en-tête de tableau. La boulangerie locale peut envoyer une facture manuscrite où le bloc adresse du fournisseur n'a aucune étiquette explicite — vous le reconnaissez car il se trouve en haut à gauche et commence par le nom de la rue. C'est l'argument central contre l'extraction par lot basée sur des modèles pour les factures allemandes : chaque nouveau fournisseur vous oblige à créer et maintenir un nouveau modèle d'extraction.
Pour mettre les choses en perspective : un groupe de restauration allemand de taille moyenne peut recevoir des factures de Metro (grossiste alimentaire), Transgourmet (boissons), un marchand de légumes local, plusieurs distributeurs de boissons, un service de nettoyage, une société de maintenance et une agence de marketing — sans compter les fournisseurs ponctuels. Cela représente huit formats de factures distincts, sans même tenir compte des variations au sein de Metro lui-même (facture standard, bon de livraison, avoir), qui utilisent la même mise en page mais réorganisent les champs. Les outils basés sur des modèles nécessitent une configuration distincte pour chaque variante. Avec l'extraction sémantique, vous définissez les noms de colonnes une seule fois.
C'est la différence entre l'approche par noms de colonnes et l'approche par modèles à grande échelle. L'extraction personnalisée de colonnes — le mécanisme utilisé par ImageToTable.ai — fonctionne en comprenant le sens des champs, et non par coordonnées. Vous saisissez les noms de colonnes souhaités : "Rechnungsnummer", "Lieferant", "Rechnungsdatum", "Leistungsdatum", "Nettobetrag", "USt-Satz", "USt-Betrag", "Bruttobetrag", "USt-IdNr" — et l'IA localise chaque valeur sur chaque facture du lot en comprenant la signification de l'étiquette, peu importe où elle apparaît ou si le texte de l'étiquette varie ("Rechnungs-Nr." vs "Rechnungsnummer" vs "RNr."). Une seule définition de colonne couvre les huit mises en page de fournisseurs en un seul téléchargement par lot.
L'implication pratique : vous téléchargez le dossier complet du mois contenant les factures entrantes — 80 PDF, JPG et documents scannés de tous les fournisseurs — et vous obtenez un seul tableau fusionné où chaque ligne représente une facture avec les mêmes colonnes, quel que soit le format. Pas de modèle par fournisseur, pas de tri préalable par format, pas de « les factures de ce fournisseur doivent être téléchargées séparément car la mise en page est différente ».
La répartition des taux de TVA sur 80 factures — pourquoi une seule colonne « Taxe » ne suffit pas
Supposons que l'extraction par lot ait fonctionné — les 80 factures sont dans votre tableur avec des colonnes cohérentes. Le problème suivant est que la colonne Taux de TVA contient quatre valeurs différentes — 19 %, 7 %, 0 % (ou vide) et « §13b » — et chacune exige un traitement comptable distinct. Si vous additionnez simplement la colonne Montant de la TVA, vous cumulez la TVA normale à 19 % déductible en tant que Vorsteuerabzug (selon §15 UStG), la TVA réduite à 7 % également déductible mais à déclarer séparément (ligne 66 de la Umsatzsteuervoranmeldung), et les montants §13b où l'obligation de TVA est transférée au destinataire — donc aucune déduction et une déclaration séparée.
La Umsatzsteuervoranmeldung — la déclaration mensuelle ou trimestrielle de TVA en Allemagne, déposée via ELSTER — exige que les montants de TVA soient déclarés sous des codes fiscaux spécifiques (Kennzahlen) :
| Scénario TVA | ELSTER Kennzahl | Signification dans un lot | Ce que votre tableur doit contenir |
|---|---|---|---|
| Taux normal 19 % | Kennzahl 66 | TVA en amont déductible — la catégorie la plus courante pour la plupart des entreprises | Lignes où USt-Satz = 19 % → SOMME(USt-Betrag) → va dans Kz 66 |
| Taux réduit 7 % | Kennzahl 66 (sous-ensemble) | Également déductible, mais votre Steuerberater peut souhaiter voir la répartition | Lignes où USt-Satz = 7 % → SOMME(USt-Betrag) → sous-total séparé, toujours Kz 66 |
| Autoliquidation §13b | Kennzahl 46+47 | Vous auto-liquidez la TVA et la déduisez dans la même déclaration — solde nul, mais doit être déclaré | Lignes où USt-Satz = §13b → signaler au Steuerberater, ne pas inclure dans Kz 66 |
| §19 Kleinunternehmer | Sans objet | Pas de TVA sur la facture = pas de déduction à demander. Reste une charge professionnelle valide. | Lignes où USt-Satz = vide/0 — pas de saisie TVA nécessaire, mais Nettobetrag reste pertinent comme Aufwand |
| Facture de faible montant (§33 UStDV) | Kz 66 (si TVA incluse) | Factures inférieures à 250 € brut — mentions obligatoires simplifiées, mais la TVA s'applique toujours | Peut ne pas indiquer explicitement la TVA — calculer 19/119 ou 7/107 à partir du Brutto si nécessaire |
Une approche pratique pour gérer cela dans une extraction par lots : définir une colonne déduite — une colonne où l'IA classe la facture en fonction de son contenu plutôt que d'extraire une valeur explicite sur la page. Par exemple, une colonne nommée Type de TVA (options : Standard 19 %/Réduit 7 %/§13b Autoliquidation/Kleinunternehmer §19) demande à l'IA de lire chaque facture, de déterminer le régime de TVA applicable et de renvoyer la catégorie correcte. Vous obtenez ainsi une colonne filtrable — et à partir de là, vous regroupez par type de TVA et additionnez le montant de TVA de chaque groupe séparément pour votre déclaration de déduction de taxe en amont. L'extraction et la classification se font en une seule passe, et non en deux opérations distinctes.
Cela compte aussi pour le côté dépenses de votre comptabilité. Le montant net d'une facture §13b reste une charge d'exploitation (Aufwand), même sans TVA en amont — si vous l'excluez de votre récapitulatif des coûts parce que « pas de TVA = pas pertinent », vous sous-estimez vos dépenses. L'extraction par lots doit capturer l'ensemble du tableau financier, pas seulement la partie liée à la TVA.
De l'extraction par lots à votre expert-comptable — prêt pour DATEV en un seul export
Extraire 80 factures dans un tableur résout le problème de saisie des données. Cela ne résout pas automatiquement le problème de transfert — l'étape où ce tableur doit devenir quelque chose que votre expert-comptable peut importer dans DATEV sans ressaisir chaque ligne. Les conseillers fiscaux allemands utilisent les plateformes Kanzlei-Rechnungswesen et Unternehmen Online de DATEV, qui importent les données via deux mécanismes par lots principaux :
Import CSV (format DATEV) pour Kanzlei-Rechnungswesen — un CSV à colonnes fixes avec un ordre de champs spécifique : Belegdatum, Buchungstext, Gegenkonto, Betrag, indicateur Soll/Haben, et optionnellement le Buchungsschlüssel (clé de comptabilisation) et le Kontierung (numéro de compte selon SKR03 ou SKR04). Le fichier doit utiliser le point-virgule comme séparateur, l'encodage ISO-8859-1 et le format de date JJ.MM.AAAA — les exportations CSV d'outils anglophones qui utilisent par défaut la virgule et MM/JJ/AAAA échoueront silencieusement.
Import XML (jobs dxso) pour DATEV Unternehmen Online — une soumission de lots via le schéma XML propriétaire de DATEV. Le mécanisme dxso (DATA XML Send Online) accepte des données de facture structurées en documents XML, validées selon les schémas XSD de DATEV. Le XML est obligatoire pour Unternehmen Online ; le CSV est destiné à l'application de bureau Rechnungswesen — et votre Steuerberater peut utiliser l'un ou l'autre, ou les deux, selon son flux de travail.
Le point clé : vos colonnes d'extraction doivent refléter les colonnes d'import attendues par votre système cible. Si votre Steuerberater a besoin du Belegdatum au format JJ.MM.AAAA, définissez votre colonne d'extraction comme « Belegdatum » — pas « Date de facture ». S'il comptabilise les dépenses sur le compte 4930 (SKR03 : Autres frais), incluez une colonne intitulée « SKR03 Konto » avec le code approprié. Cela évite l'étape intermédiaire de reformatage d'une extraction générique pour l'adapter aux schémas du logiciel de comptabilité. L'extraction est le fichier d'import.
Pour un lot de 80 factures destinées à DATEV, le jeu de colonnes pourrait ressembler à :
- Date du justificatif — JJ.MM.AAAA
- Texte d'écriture — combinaison Fournisseur + N° de facture
- Compte collectif — le numéro de créditeur du fournisseur (série 70000 dans SKR04)
- Montant — montant brut
- Débit/Crédit — « S » pour débit (charge), « H » pour crédit
- Compte SKR03 — le compte de charge (ex. 4930 pour frais divers, 3400 pour marchandises)
- Taux de TVA — 19 ou 7 ou 0
- Montant de TVA déductible — le montant de TVA récupérable
Lexware Office et sevDesk utilisent leurs propres modèles CSV, mais le principe reste le même : définir des colonnes d'extraction correspondant au schéma d'import, exporter en CSV, et importer directement. La promesse du traitement par lots — 80 factures en quelques minutes — n'est pleinement tenue que si le résultat ne nécessite pas une heure supplémentaire de reformatage.
Le flux de travail — Comment traiter 80 factures fournisseurs en une seule fois
Une fois les défis structurels identifiés — diversité des formats, fragmentation de la TVA et compatibilité DATEV — voici le flux de travail complet par lots, d'un dossier de 80 factures à un tableau prêt pour l'expert-comptable :
Type de TVA (options : Standard 19%/Réduit 7%/§13b Autoliquidation/Kleinunternehmer §19) pour classer automatiquement chaque facture. Pour exporter vers DATEV, alignez les noms de colonnes sur le schéma d'import (Belegdatum pas "Date", Bruttobetrag pas "Total"). Cette définition de colonnes est réutilisée pour chaque lot — vous la définissez une fois, pas par lot.Les fichiers sont traités de manière sécurisée et non stockés. Importez plusieurs Rechnungen pour voir l'extraction par lot en action.
Pour l'étape de vérification précisément : les éléments les plus risqués d'un lot ne sont pas ceux qui semblent erronés — ce sont ceux qui semblent corrects mais contiennent un champ systématiquement mal interprété en raison d'une bizarrerie de formatage propre au fournisseur. Une facture Metro dont le Nettobetrag est aligné différemment des 79 autres factures n'affichera pas d'erreur — la cellule contiendra un nombre, et ce nombre semblera plausible. Le contrôle qui détecte cela est la vérification ponctuelle des 10 premières par Bruttobetrag : ouvrez la facture Metro originale, comparez le total brut au total brut extrait. S'ils correspondent, l'extraction est probablement correcte. Sinon, il y a une bizarrerie de formatage à examiner.
Archivage Conforme GoBD — N'archivez pas le Fichier Excel, Archivez les Originaux
Le traitement par lots crée un raccourci tentant : extraire 80 factures dans un seul tableur propre, archiver le tableur, et supprimer les originaux en désordre. C'est l'erreur de conformité GoBD la plus courante dans le traitement automatisé des factures — et elle échoue aux exigences d'audit à plusieurs niveaux.
Les GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern), révisées en juillet 2025 pour s'aligner sur l'obligation de facturation électronique en Allemagne, exigent que les documents fiscalement pertinents soient conservés dans leur format original reçu, et non dans une version dérivée ou transformée. Plus précisément :
- Factures électroniques structurées (XML XRechnung, PDF hybride ZUGFeRD) : Le XML fait foi fiscalement. Si la facture est arrivée en PDF ZUGFeRD, l'intégralité du fichier PDF/A-3 (XML inclus) doit être archivée comme un seul bloc. L'amendement de juillet 2025 confirme qu'une copie PDF lisible séparée n'est pas obligatoire, sauf si elle contient des informations fiscales supplémentaires absentes du XML — comme des annotations manuscrites sur la couche visuelle.
- PDF simples et documents scannés : Le fichier original doit être conservé intact pendant 10 ans conformément au §147 AO. Une ligne extraite dans Excel est une copie de travail, pas un substitut d'archive.
- Factures papier photographiées : La photo numérique devient le document de référence. Le principe GoBD d'Unveränderbarkeit (immuabilité) exige que le fichier photo soit stocké de manière à empêcher toute modification ultérieure — horodaté, haché ou conservé dans un système verrouillé.
Le résultat de l'extraction — votre tableur Excel de 80 lignes — est un document opérationnel, pas un document d'archives. Il sert à votre comptabilité courante, au calcul de la TVA déductible et à l'import DATEV. Lors d'une Betriebsprüfung (contrôle fiscal), l'inspecteur demandera les fichiers factures originaux, pas votre tableur d'extraction. L'extraction doit seulement permettre de retracer ces originaux — ce qui implique que le tableur inclue une colonne identifiant le fichier source pour chaque ligne (nom de fichier ou numéro de référence). Sans cette colonne de traçabilité, une extraction groupée de 80 factures produit 80 lignes de données impossibles à vérifier par rapport à leurs sources — un manquement à la conformité GoDB, quelle que soit la précision de l'extraction.
Le flux de travail pratique pour l'archivage par lots : conservez les fichiers originaux dans un dossier daté (ex. /Eingangsrechnungen/2026-05/), nommez-les de manière cohérente (2026-05-03_Metro_INV-48291.pdf), et assurez-vous que votre résultat d'extraction conserve le nom de fichier comme colonne. Si votre Steuerberater utilise DATEV Unternehmen Online, les fichiers de facture originaux peuvent être joints aux écritures correspondantes via la fonction Belegverwaltung (gestion des documents) — bouclant ainsi la traçabilité du tableur au document source et jusqu'à la piste d'audit DATEV.
Le mandat progressif de facturation électronique en Allemagne — réception obligatoire depuis janvier 2025, envoi obligatoire pour les entreprises de plus de 800 000 € de chiffre d'affaires à partir de 2027, envoi universel à partir de 2028 — réduit progressivement le problème des « originaux désordonnés ». À mesure que les fournisseurs migrent vers ZUGFeRD et XRechnung, la couche XML intégrée fournit des données structurées sans OCR. Mais pendant la période de transition, votre pipeline par lots traitera un mélange : certains PDF ZUGFeRD, certains PDF simples, certaines Rechnungen scannées de fournisseurs qui ne basculeront pas avant 2028. Le flux d'extraction doit gérer les trois, et le flux d'archivage doit conserver les trois dans leurs formats d'origine respectifs.
Questions fréquentes
Puis-je vraiment traiter des factures de Metro, Transgourmet et d'un artisan local dans le même lot ?
Oui. Comme l'extraction repose sur la sémantique des noms de colonnes — l'IA lit le sens du champ, pas sa position — la même définition de colonne (Rechnungsnummer, Lieferant, Bruttobetrag, etc.) fonctionne avec différentes mises en page de fournisseurs. Pas besoin de modèle séparé par fournisseur. Une seule réserve : si deux fournisseurs utilisent le même libellé pour des choses différentes (ex. : un champ "Datum" signifiant date de facture chez l'un et date de livraison chez l'autre), définissez vos colonnes avec précision — "Rechnungsdatum" et "Lieferdatum" plutôt qu'un générique "Date".
Comment gérer la répartition de la TVA quand certaines factures ont des articles à 19 % et 7 % ?
Pour les factures à taux de TVA mixtes, définissez des paires de colonnes distinctes : "Nettobetrag 19 %", "USt-Betrag 19 %", "Nettobetrag 7 %", "USt-Betrag 7 %". L'IA extrait chaque groupe de taux indépendamment de la facture. Si une facture ne contient que des articles à 19 %, les colonnes 7 % seront vides — et inversement. Dans votre export par lot, vous pouvez ensuite additionner les colonnes USt-Betrag 19 % et USt-Betrag 7 % séparément pour votre calcul de Vorsteuerabzug. Pour les factures complexes où la répartition n'est pas claire — une facture de restaurant mélangeant nourriture (7 %) et alcool (19 %) sur la même ligne — ajoutez une Colonne calculée pour recalculer la répartition correcte à partir des quantités et prix unitaires, et recoupez avec la ventilation de TVA indiquée sur la facture.
Que se passe-t-il si une facture du lot a un champ manquant — cela bloque-t-il tout le lot ?
Non. L'IA traite chaque facture indépendamment dans le lot. Si la facture n°23 n'a pas de numéro de TVA (courant pour les Kleinbetragsrechnungen sous 250 €, qui n'en exigent pas), cette cellule sera vide pour cette ligne — toutes les autres lignes restent inchangées. L'étape de vérification dans le workflow est conçue pour détecter cela : triez par la colonne obligatoire et cherchez les vides. Vous pouvez alors soit saisir manuellement la valeur manquante (si vous connaissez le numéro de TVA du fournisseur d'une facture précédente), accepter le vide s'il est légitime (Kleinbetragsrechnung), ou le signaler pour relance fournisseur s'il s'agit d'un champ obligatoire sur une facture complète.
Puis-je exporter directement au format CSV DATEV depuis l'extraction par lot ?
Vous pouvez exporter en Excel (XLSX) ou CSV, puis mapper les colonnes vers le format CSV DATEV requis par votre Steuerberater. Le résultat de l'extraction par lot est un tableur structuré — les colonnes que vous avez définies deviennent les colonnes Excel. Si vous nommez vos colonnes pour correspondre aux champs d'import DATEV (Belegdatum, Buchungstext, Gegenkonto, Betrag, etc.), l'export a déjà la bonne structure — vous devrez peut-être réorganiser l'ordre des colonnes et vous assurer que le délimiteur et les formats de date correspondent aux spécifications exactes de DATEV (point-virgule, JJ.MM.AAAA, encodage ISO-8859-1). L'outil ne produit pas nativement du CSV au format DATEV, mais les données extraites y correspondent directement avec un minimum de reformatage.
Le traitement par lots fonctionne-t-il avec des factures XML ZUGFeRD et des factures papier scannées mélangées dans le même fichier ?
Oui, le lot peut contenir un mélange de PDF ZUGFeRD, PDF simples, scans JPG et photos — l'IA lit la couche visuelle de chaque document. Pour les factures ZUGFeRD, elle lit le rendu PDF visible ; elle n'analyse pas le XML intégré. En pratique, la précision d'extraction d'une facture ZUGFeRD dépend de la qualité visuelle de la mise en page, et non de la présence du XML — comme pour un PDF simple. Pour les fichiers XML XRechnung purs (sans PDF visuel), l'outil n'est pas conçu pour les traiter — utilisez un convertisseur XML vers CSV, ou demandez au fournisseur de fournir également la version PDF lisible.
Comment gérer l'escompte (Skonto) dans l'extraction par lots ?
L'escompte — généralement 2-3 % de réduction pour paiement sous 7-14 jours — est souvent indiqué dans une note plutôt que dans un champ dédié (ex. « 2 % Skonto bei Zahlung innerhalb 10 Tagen »). Si vous devez le suivre, définissez une colonne « Escompte (%) » — l'IA extraira le pourcentage s'il est mentionné sur la facture. Pour le montant net, vous souhaitez généralement le montant total avant escompte (base de calcul), et non le montant réduit, car la TVA est calculée sur le montant total conformément au §10 UStG. Si la facture indique le total après escompte, utilisez une colonne calculée pour retrouver le montant net avant escompte à des fins de déduction de la TVA en amont, l'administration fiscale déterminant la TVA sur le montant brut avant réduction.
Mettre en place votre traitement par lots de factures allemandes
Le traitement par lot des Eingangsrechnungen allemandes se situe à un carrefour précis : c'est le point où le nombre de factures passe de « la saisie manuelle est agaçante mais gérable » à « la saisie manuelle est un gouffre structurel de temps ». Pour la plupart des PME allemandes, ce seuil se situe entre 40 et 60 factures par mois. En dessous, la friction vient du flux de travail — ouvrir DATEV, saisir les champs, enregistrer. Au-dessus, la friction est systémique : diversité des formats, fragmentation de la TVA et lacunes de traçabilité qui survivent à tout flux de facture unique.
L'approche de traitement par lot décrite ici — extraction basée sur les noms de colonnes qui fonctionne avec tous les formats de fournisseurs, colonnes déduites pour la classification automatique de la TVA et schémas d'exportation alignés sur DATEV — s'attaque aux problèmes systémiques, pas seulement à la vitesse par facture. Le gain d'efficacité de 18x (3 minutes par facture en manuel contre 5 à 10 secondes avec l'extraction) est le chiffre phare. Mais le changement opérationnel le plus important est celui-ci : l'ensemble des Eingangsrechnungen du mois devient une seule opération. Pas 80 opérations effectuées rapidement — une seule opération effectuée une fois. La différence est celle entre « je suis devenu plus rapide en saisie de données » et « la saisie de données a cessé de faire partie de ma clôture mensuelle ».
Téléchargez plusieurs Rechnungen — essai gratuit, sans compte requis pour les 50 premières pages.