E‑Rechnungen prüfen: ZUGFeRD, XRechnung, Peppol und EN 16931 verstehen

Петък, 15:40 ч.: Поступленията на фактури са на входа. Не пълни – но точно толкова, че да боли. Част от входящите електронни фактури преминава гладко, друга част остава блокирана в импортиращата верига. Функционалната страна казва: „В PDF всичко изглежда коректно.“ IT вижда в логовете: „Профил не е допустим“ и „Нарушено е бизнес правило“. Оттам нататък става политическо: отделът за покупки иска пропускателна способност, счетоводството иска сигурност, IT не иска специална логика за всеки доставчик.

Който в такава ситуация да проверява E‑Rechnungen, бързо разбира: ZUGFeRD, XRechnung, Peppol и EN 16931 не са игра на думи, а въпрос на преценка. В зависимост от това колко строго проверявате, се променят усилията и рискът – и с това и архитектурните решения (централен Prüfservice vs. Plugin im ERP), оперативните въпроси (Monitoring, Updates, Fallback) и въпросите при разгръщане (пилотни групи, комуникация с доставчици, класове грешки).

Две цели, които в ежедневието се изтеглят взаимно

Цел 1: Автоматизация с висок пропускателен капацитет. Много компании искат да организират входящите фактури така, че структурирани фактури да попадат в ERP, работен поток и архив без прекъсвания на медиите. Това намалява ръчното въвеждане и ускорява одобренията – но само ако данните са надеждни.

Цел 2: Сигурност на проверката с проследим доказателствен запис. В спорен случай трябва да може да се документира защо една фактура е приета или отхвърлена: кой профил, кое правило, коя версия. Това става особено важно, когато доставчици подават рекламации („вие отхвърлихте, а при други мина“) или вътрешните контролни органи изискват чиста верига на документите.

Двете цели са легитимни. Конфликтът възниква, защото всяка допълнителна проверка намалява рисковете, но също така създава повече специални случаи. Това е особено валидно, когато доставчици изпращат различни профили или смяната на версия в спецификацията още не е навсякъде приложена.

EN 16931: Защо при проверките трябва да управлявате семантиката вместо „формата на файла“

EN 16931 в проектната практика често се нарича „XML-формат“. По-полезна за практиката е друга гледна точка: EN 16931 е семантичен модел на данните за основните елементи на електронната фактура – тоест значението на полетата и свързаните с тях бизнес правила (Business Rules) за съответствие. Европейската комисия класифицира EN 16931 именно така: като семантичен модел на основните елементи, включително правила за съответствие.^{[Източник]}

Практическото следствие за ИТ и експлоатация: „XML е правилно формирано“ е само входната врата. Решаващо е дали една фактура е консистентна по смисъл (логика на сумите, данъчни данни, задължителни полета, кодове). И дали е представена в правилния профил – защото профилите определят кои части от стандарта и в какво изпълнение са приложими.

Също така е важно стандартите да не се разглеждат като статични. В регистрите на стандарти вече е посочено актуализирано издание като EN 16931‑1:2026.^{[Източник]} Това не означава, че трябва да преминете веднага. Означава обаче: вашият модел за проверка и експлоатация трябва да е изграден така, че наборите от правила и валидаторите да могат да се версионират и контролирано да се актуализират – без цялата обработка при всяка актуализация да е „на ръба“.

ZUGFeRD und XRechnung: Zwei Wege, dieselbe Pflicht praktisch zu machen

В Германия в много компании се срещат две разпространени форми:

• ZUGFeRD като хибриден формат: PDF/A‑3 файл, в който са вградени структурирани данни за фактурата (XML). FeRD описва ZUGFeRD 2.2 експлицитно като хибриден модел: четим документ плюс машинночитаемо XML в PDF/A‑3.^{[Източник]}
• XRechnung като изцяло структуриран формат: фокусът е напълно върху машинно обработваемите данни, без PDF да бъде включено като част.

Оценката е по-малко идеологическа и повече оперативна: ZUGFeRD често е по-лесно приеман от бизнес отделите, защото съществува четим документ. В същото време PDF не бива да води до пренебрегване на XML-проверката. XRechnung е изрично ориентиран към данните и следователно подходящ за автоматизация, но в практиката почти винаги изисква добро средство за визуализация и проверка, което представя съдържанието разбираемо.

Правна рамка: Какво от 2025 г. се счита за „E‑Rechnung“

За планирането на проекта едно твърдение е особено релевантно: В контекста на ДДС от 01.01.2025 електронна фактура се счита за такава само ако е издадена/предадена/получена в структуриран електронен формат и позволява електронна обработка.^[Quelle] Само PDF файл без структурирани данни не попада в дефиницията, която е релевантна тук.

BMF посочва също XRechnung както и ZUGFeRD от версия 2.0.1 (с изключения на профили) като формати, които по принцип изпълняват данъчните изисквания.^[Quelle] От оперативна гледна точка това не е „религиозен“ спор за формати, а ясно задължение: Трябва да разпознавате, проверявате и проследимо документирате профила и версията. В противен случай не е възможна нито надеждна контролна точка, нито ясен доказателствен материал защо една фактура е била обработена така.

Peppol richtig einordnen: Transport und Interoperabilität statt „noch ein Format“

Peppol често се третира в ежедневната работа като още един формат за фактури. Това води до погрешни очаквания. Peppol е на първо място рамка за предаване и интероперабилност за структурирани търговски документи. За фактурите релевантният компонент е Peppol BIS Billing 3.0.

В официалната BIS-Billing документация съвместимостта с EN‑16931 е видима чрез CustomizationID-схемата (т.е. чрез идентификатор, който описва профила/„Customization“-контекста). Това е важно, защото показва: В Peppol-средата идентификаторите за профил и съвместимост са част от машинната обработка и не са просто „nice to have“.^[Quelle]

Какво следва от това в експлоатация е много конкретно: Освен проверката на документа възникват и транспортни въпроси. Адресиране, участнически идентификатори, технически откази, доказателства за доставка – всичко това създава собствени модели на грешки. Ако не класифицирате тези грешки отделно, в крайна сметка всичко ще отиде при Finance като „Rechnung kaputt“ или при IT като „Peppol spinnt“.

Leitweg-ID & Peppol-ID: Защо идентификаторите са критични за продукционната среда

Ръководството за използване на входния канал Peppol за федералната администрация описва например формирането на Peppol-ID от префикса 0204 и Leitweg-ID за свързаните федерални ведомства и локализира Peppol Authority Deutschland при KoSIT.^[Quelle] Това е специфичен контекст (федерална администрация). Поучението, което може да се пренесе към компаниите, обаче е ясно: идентификаторите не са маргинална тема. Те принадлежат в Runbooks, тестови случаи и конфигурация – защото „falsche ID“ в продукция блокира по същия начин както „falsches Profil“.

Abwägungskarte: Prüfstrategie nach Nutzen, Aufwand und Risiko

Една практична стратегия разделя проверките на етапи. Вие трябва съзнателно да решите кой етап действа като твърдо Gate (отхвърляне) и кой етап само генерира предупреждение (изясняване). Следващата карта помага да се сравнят типичните опции.

E‑Rechnungen prüfen: Ein Prüfpfad, der im Betrieb standhält

Wenn Sie den Prüfprozess so formulieren, dass er in Logs, Runbooks und Ticketsystemen wiederzufinden ist, sinkt der spätere Reibungsverlust. Der folgende Pfad ist bewusst „betriebsorientiert“ und unabhängig davon, ob der Eingang per E‑Mail, Upload, API oder Peppol erfolgt.

1. Eingang erfassen: Kanal, Zeitstempel, Absender-/Empfänger-IDs, technische Metadaten. Das ist Ihre Audit-Spur.
2. Container erkennen: Reines XML? ZUGFeRD (PDF/A‑3 mit eingebettetem XML)? Sonstiges? Bei Hybrid: XML extrahieren und als separates Prüfobjekt behandeln.
3. Profil und Version bestimmen: Welche Ausprägung liegt vor (z. B. EN‑16931-Profil, XRechnung-Version, Peppol BIS Billing mit CustomizationID)? Ohne diese Info prüfen Sie ins Leere.
4. Strukturvalidierung: Schema-/Profilprüfung mit protokollierter Validator-Version und Regelset-Stand. Ergebnis muss reproduzierbar sein.
5. Semantische Regeln: EN‑16931-Business-Rules und Konsistenzprüfungen (Summen/Steuern/Pflichtlogik) auswerten.
6. Interne Geschäftsregeln: Stammdatenabgleich, Bestellbezug, Dublettencheck, Freigaberegeln, Kontierungsanforderungen. Diese Regeln sind unternehmensspezifisch und ändern sich oft häufiger als Standards.
7. Ergebnis steuern: Automatisch weiterleiten/buchen, in Klärung geben oder zurückweisen – inklusive Fehlerklasse, kurzer Begründung und Referenz auf das Prüflog.

Границата на този път: той не отговаря автоматично кое правило при вас трябва да бъде „строго“. Това е управленско решение между пропускателната способност на процеса и риска – и трябва да бъде документирано, за да могат промените по-късно да бъдат проследени.

Архитектурни последици: Централен Prüfservice или Prüfung im Zielsystem?

В проекта често възниква на пръв поглед малък въпрос: „Къде проверяваме?“ На практика той решава поддръжката и оперативните разходи.

Zentrale Validierung (Service oder Integrationsplattform)

Валидацията работи като централен сервиз: еднакви правила, еднакви класове грешки, едно място за ъпдейти. Това прави мониторинга по-лесен (например процент отхвърляния по доставчик/профил) и улеснява одитите, тъй като резултатите от проверките се съхраняват последователно.

Цената: оперирате допълнителен компонент. Висока наличност, прозорци за поддръжка, версиониране и rollback за ъпдейти на правилата стават задължителни. За сметка на това печелите контрол.

Dezentrale Validierung (ERP/DMS-Plugins, Clients)

Тук проверката се извършва в няколко системи. Това може да изглежда привлекателно на кратък срок („ERP вече може това“), но често води до разминаване: различни версии на валидаторите, различни съобщения за грешки, различни изключения. И точно това е отрова за стандартизацията и поддръжката.

За IT-руководството е полезно да има едно правило: ако са в игра няколко входни канала и няколко целеви системи, централен сервиз за проверка често е по-робустното дългосрочно решение. Ако има само един ясен път (едно ERP, един вход), децентрализираната проверка може да бъде оправдана – но тогава версионирането трябва да бъде урегулирано ясно.

Какво в проектите при проверките наистина отнема време

Техническито четене на XML рядко е проблемът. Времето и рискът възникват по ръбовете:

• Разнообразие от профили и версии: Без прозрачност кои партньори изпращат кои профили, всяко издание става полет на сляпо. Телеметрия (профил/версия за всеки вход) затова не е лукс, а инструмент за управление.
• Превод на грешки: Изходите от валидатора често са твърде сурови за функционалните отдели или доставчиците. Те се нуждаят от съпоставяне към разбираеми категории и опции за действие.
• Основни данни и процеси: Структурираните фактури правят проблемите с основните данни видими (липсващо свързване към кредитор, несъгласувани номера на поръчки). Това е полезно, но в началото води до повече случаи за изясняване.
• Верига на документите и архив: За проследимост не е достатъчно „Datei abgelegt“. Решаващо е: оригиналът (PDF/XML), резултатът от проверката, версията на набора от правила, моментът и връзката с бизнес процеса (одобрение, осчетоводяване).

Въвеждане без прекъсване на процеса: вълни, резервен механизъм и измерими критерии

Стабилно въвеждане се постига, когато не пускате всичко едновременно в продукция. Практиката показва, че ефективна е логика на вълни:

• Pilot: малък брой доставчици и видове документи, много детайлно логиране, ежедневен преглед на най-честите класове грешки.
• Stabilisierung: прецизиране на правилата, но с прозорци за промяна и ясна комуникация. Повтарящите се моделни грешки да се изясняват целенасочено с отдел за покупки/доставчици.
• Skalierung: прехвърляне на мониторинга в редовна експлоатация (процент на отхвърляния, време за изясняване, водещи нарушения на правилата, дял на ръчната обработка).

Планирайте също така аварийна експлоатация. Ако едно обновление на правилата внезапно блокира много фактури, ви е нужен контролиран Fallback (например временно предупреждаващ режим вместо твърдо отхвърляне) – с документирано решение и последваща проверка. Това не е „омекотител“, а оперативна спирачка срещу неконтролирани спирания.

Три типични недоразумения, които трябва да изчистите рано

1) „ZUGFeRD ist wie früher ein PDF.“ В процеса има значение вградената XML. PDF-то е полезно за хората, но не замества машинната проверка. Ако PDF и XML се разминават, трябва да е ясно кой източник важи в процеса.

2) „Peppol macht automatisch alles konform.“ Peppol помага при обмена и при интероперабилността. Съответствието се постига само чрез коректно съдържание и подходящи профили. Доставянето не е равно на валидиране.

3) „Wenn der Validator grün ist, kann gebucht werden.“ Стандартната съвместимост е основа, не пълна процесна одобрение. Вътрешните правила (задължение за поръчка, прием на стока, граници на одобрение) остават в сила и трябва да се водят като отделна стъпка, вместо да се смесват в логиката на валидатора.

Заключение: Добрата проверка облекчава – когато е изградена като оперативен процес

Проверката на електронните фактури не е самоцел. Ползата идва, когато валидирането се мисли като оперативна система: версионирано, наблюдаемо, с ясни класове грешки и обратен канал, който не се губи в опашка от тикети. Тогава стандарти като EN 16931, профили като XRechnung/ZUGFeRD и транспортни пътища като Peppol не се превръщат в дълготраен проблем, а в управлявани компоненти във вашата процесна верига.

За тази тема също са важни проверката на ZUGFeRD и валидацията на XRechnung. Статията подрежда тези аспекти по разбираем начин и показва на какво да се обръща внимание в практиката.

Обсъдете проект или план за модернизация с Net-Base.