SAP Business One en Allemagne : E-Rechnung, DATEV, GoBD

En Allemagne, SAP Business One fonctionne sur une localisation officielle de SAP : le paramétrage de la TVA allemande, les rapports de taxe, l’export DATEV et les formats de facture électronique viennent de SAP lui-même. Ce qui change en ce moment pour les entreprises allemandes, c’est la facture électronique (E-Rechnung) : la réception est obligatoire depuis 2025, et l’émission le devient en 2027 ou 2028. Cette page présente ce que couvre la localisation, les dates applicables et les cas où un développement sur mesure sur SAP B1 est utile.

Je suis Zain Abbas, développeur SAP Business One. Pendant 2,5 ans, j’ai travaillé au sein de l’équipe d’une entreprise allemande sur des add-ons de production SAP B1, des portails web et une intégration téléphonique 3CX. C’est l’expérience allemande derrière cette page ; les règles ci-dessous proviennent du ministère fédéral des Finances (BMF) et de la documentation SAP, cités en fin de page.

Que comprend la localisation allemande de SAP Business One ?

SAP livre SAP Business One avec des localisations par pays, et l’Allemagne en fait partie (tout comme l’Autriche et la Suisse, chacune avec sa propre localisation). Le guide du SAP Help Portal « Localization for Germany » pour la version 10.0 couvre :

Lorsque vous créez une nouvelle société dans SAP Business One, vous choisissez la localisation, et elle ne peut plus être changée ensuite. Une entité allemande doit donc être créée sur la localisation Allemagne dès le premier jour. Une société démarrée sur une autre localisation qui a besoin plus tard des déclarations allemandes implique en général une nouvelle base de données société et une migration des données, pas un simple paramètre.

À partir de quand les entreprises allemandes doivent-elles émettre des factures électroniques ?

L’obligation découle de la loi sur les opportunités de croissance (Wachstumschancengesetz) et elle est expliquée dans la FAQ du BMF et dans la circulaire du BMF du 15 octobre 2025. Pour les factures B2B nationales :

1. Depuis le 1er janvier 2025 : toute entreprise nationale doit pouvoir recevoir des factures électroniques. Une boîte e-mail suffit.
2. Jusqu’au 31 décembre 2026 : les émetteurs peuvent encore émettre d’autres factures (papier, ou PDF avec l’accord du destinataire).
3. Jusqu’au 31 décembre 2027 : les émetteurs dont le chiffre d’affaires de l’année précédente ne dépassait pas 800 000 EUR peuvent encore émettre d’autres factures.
4. Ensuite : les factures B2B nationales doivent être des factures électroniques.

Une facture électronique désigne ici un format structuré conforme à la norme européenne EN 16931. Les deux formats les plus cités sont XRechnung, un fichier XML pur, et ZUGFeRD / Factur-X, un PDF/A-3 avec le XML intégré, lisible par une personne et exploitable par un logiciel. L’Allemagne n’impose pas de réseau de transmission pour le B2B : l’e-mail convient, et Peppol est facultatif en B2B tout en étant très utilisé pour les factures aux administrations (B2G).

C’est différent des modèles de validation préalable (clearance) que j’ai mis en œuvre dans d’autres pays, comme le Guatemala ou le Salvador, où chaque facture passe par l’administration fiscale avant ou juste après son émission. L’Allemagne n’a pas encore de plateforme centrale pour les factures B2B ; la facture va directement du vendeur à l’acheteur.

Ce que cela signifie dans SAP Business One

Le côté réception est souvent sous-estimé. Depuis 2025, votre équipe comptabilité fournisseurs reçoit des fichiers XML et des PDF hybrides. Quelqu’un doit les contrôler et les comptabiliser comme factures fournisseurs (OPCH), idéalement sans ressaisie. Le guide ZUGFeRD de la localisation allemande est le point de départ ; les entreprises qui reçoivent beaucoup de factures ajoutent en général un outil de traitement des documents entrants.

Côté émission, les données doivent être complètes pour que la facture électronique soit valide. En pratique, les lacunes se trouvent dans les données de base, pas dans le XML : numéros de TVA manquants sur les partenaires commerciaux (OCRD.LicTradNum), références acheteur manquantes pour les clients du secteur public (la Leitweg-ID) et codes de taxe erronés sur les lignes. Une requête ou une règle de validation dans SAP B1 permet de les repérer des mois avant l’échéance.

-- SQL Server: German customers with A/R invoices this year but no VAT ID
SELECT DISTINCT T0.CardCode, T0.CardName, T0.LicTradNum
FROM OCRD T0
INNER JOIN OINV T1 ON T1.CardCode = T0.CardCode
INNER JOIN CRD1 T2 ON T2.CardCode = T0.CardCode AND T2.AdresType = 'B'
WHERE T0.CardType = 'C'
  AND T2.Country = 'DE'
  AND T1.DocDate >= '20260101'
  AND (T0.LicTradNum IS NULL OR T0.LicTradNum = '')

-- SAP HANA version
SELECT DISTINCT T0."CardCode", T0."CardName", T0."LicTradNum"
FROM OCRD T0
INNER JOIN OINV T1 ON T1."CardCode" = T0."CardCode"
INNER JOIN CRD1 T2 ON T2."CardCode" = T0."CardCode" AND T2."AdresType" = 'B'
WHERE T0."CardType" = 'C'
  AND T2."Country" = 'DE'
  AND T1."DocDate" >= '20260101'
  AND (T0."LicTradNum" IS NULL OR T0."LicTradNum" = '')

Pour éviter de nouvelles lacunes, une règle dans SBO_SP_TransactionNotification peut bloquer une facture client destinée à un client allemand sans numéro de TVA. Mon guide TransactionNotification (en anglais) montre le principe pour les deux bases de données. La page de la table OCRD (en anglais) liste les champs des partenaires commerciaux.

Pour être clair sur le périmètre : je ne vends pas de connecteur de facture électronique allemande. Les fonctions XRechnung et ZUGFeRD viennent de la localisation SAP et des partenaires SAP en Allemagne. J’interviens autour : contrôles de données, règles de validation, add-ons et intégrations.

Comment SAP Business One fonctionne-t-il avec DATEV ?

La plupart des entreprises allemandes ont un conseiller fiscal (Steuerberater) qui travaille dans DATEV. SAP documente une DATEV FI Interface pour SAP Business One. Le paramétrage décrit dans le guide SAP comporte quatre étapes : vérifier l’affectation des codes de taxe DATEV, paramétrer les partenaires commerciaux, paramétrer les comptes généraux (y compris les relations m:n entre comptes SAP et comptes DATEV), puis exporter un fichier DATEV FI. Le guide consacre des sections distinctes aux cas particuliers de comptabilisation et à l’export des données de base.

D’après mon expérience de ce type d’export, trois points comptent davantage que le bouton d’export :

• Le mapping des comptes d’abord. Si le plan comptable SAP B1 ne correspond pas proprement au plan DATEV (SKR03 ou SKR04) de votre conseiller, l’export fonctionne, mais le conseiller corrige des écritures à la main chaque mois.
• Les numéros de comptes clients et fournisseurs. DATEV attend des comptes de tiers numériques. Des codes de partenaires comme C20000 nécessitent un mapping, et ce mapping ne doit plus changer une fois les exports commencés.
• Les codes de taxe. Chaque code de taxe SAP présent dans les écritures doit avoir une clé de taxe DATEV. Une affectation manquante se traduit par des écritures que le conseiller ne peut pas comptabiliser automatiquement.

Que signifient les GoBD pour un système SAP Business One ?

Les GoBD sont les principes du BMF pour la tenue et la conservation électroniques des livres et des pièces. Avec le § 147 du code fiscal allemand (Abgabenordnung), qui donne au vérificateur fiscal un droit d’accès aux données comptables, ils fixent les règles qui comptent pour un ERP :

• Les documents comptabilisés ne doivent pas être modifiés sans trace. SAP B1 comptabilise les documents et les corrige par des avoirs ou des documents d’annulation, ce qui respecte ce principe. Les add-ons sur mesure doivent suivre la même logique : ne jamais modifier directement en SQL les valeurs d’un document comptabilisé.
• Les données doivent rester lisibles et accessibles au vérificateur pendant toute la durée de conservation, y compris après un changement de système ou une mise à niveau.
• Les factures électroniques doivent être conservées dans le format reçu. L’original est le XML, pas son impression.

Pour le développement sur mesure, c’est une règle de conception. Les add-ons que j’écris comptabilisent via la DI API ou le Service Layer, si bien que les règles métier et les journaux de modification de SAP s’appliquent. Les écritures directes dans les tables SAP ne sont pas prises en charge par SAP et iraient aussi à l’encontre du principe de traçabilité des GoBD.

Quels ERP sont répandus en Allemagne ?

Le marché allemand des ERP pour PME et ETI est très concurrentiel. On rencontre souvent SAP Business One, Microsoft Dynamics 365 Business Central, Sage, les solutions de DATEV (surtout côté comptabilité et conseillers fiscaux), Lexware pour les petites entreprises, et des ERP allemands de milieu de marché comme abas et proALPHA. Odoo et weclapp apparaissent dans les entreprises qui privilégient le cloud.

Il n’existe pas de meilleur système pour tout le monde. Si vous êtes encore en phase de choix, comparez-les selon vos processus, la façon de travailler de votre conseiller fiscal et vos besoins en facture électronique. Notre sélecteur d’ERP (en anglais) est un point de départ neutre pour cette comparaison.

Que peut faire Kodenova pour les utilisateurs de SAP Business One en Allemagne ?

Je travaille à distance, et le Pakistan a 3 à 4 heures d’avance sur l’Allemagne selon l’heure d’été, si bien que l’essentiel d’une journée de travail allemande recoupe la mienne. Voici le travail que je réalise pour des entreprises sous SAP B1, en Allemagne et ailleurs :

• Des add-ons dans SAP B1 avec l’UI API et la DI API : étapes de production, écrans d’approbation, scan, contrôles. Voir le guide de développement d’add-ons (en anglais).
• Des intégrations via le Service Layer : boutiques en ligne, CRM, téléphonie, logistique. Le guide du Service Layer (en anglais) présente la méthode.
• Des portails pour les collaborateurs, clients ou fournisseurs qui n’ont pas besoin d’une licence SAP B1 complète.
• Des requêtes, des rapports et la migration de SQL Server vers HANA des requêtes existantes. Voir le guide de migration (en anglais).
• De l’IA au-dessus de SAP B1 : un serveur MCP pour que ChatGPT ou Claude répondent à partir des données SAP en direct, avec gestion des droits.

Le projet allemand derrière cette page est décrit dans l’étude de cas add-ons de production, portails et téléphonie 3CX pour SAP B1 (en anglais) : identification de l’appelant à partir des données SAP B1 lors d’un appel entrant, add-ons de production pour les ordres, les sorties et les entrées, et portails web pour les collaborateurs hors du client SAP, livrés sur 2,5 ans.

Kodenova est indépendante et ne revend pas de licences. Si vous avez un partenaire SAP pour les licences et le support, je travaille à ses côtés sur le développement.

Sources

• Bundesministerium der Finanzen: FAQ on the mandatory e-invoice (E-Rechnung)
• Bundesministerium der Finanzen: BMF letter of 15 Oct 2025 on the introduction of the mandatory e-invoice (PDF)
• SAP Help Portal: Localization for Germany, SAP Business One 10.0
• SAP Help Portal: How to Create a XRechnung in the Germany Localization (PDF)
• SAP Help Portal: How to Work with ZUGFeRD Files in the Germany Localization (PDF)
• SAP Help Portal: DATEV FI Interface for SAP Business One
• Abgabenordnung § 147 (conservation et accès aux données), gesetze-im-internet.de

Related services

• Développement SAP Business One
• Portails web et B2B