За насУслугиПроектиСтатии

Интеграция на електронно фактуриране: Peppol, XRechnung, ZUGFeRD и Factur-X за системи, които не са създадени за това

Да купите продукт за електронно фактуриране е лесно. Проблемът почти никога не е в продукта. Той е в системата за управление на поръчки на дванадесет години, която издава фактурите ви, в ценовата логика, която никой не е документирал, и в това, че номерата на фактурите ви идват от съхранена процедура, написана от човек, напуснал през 2019 г.

Изграждаме връзката между това, с което реално работите, и това, което изисква законът. Генериране на структурирани фактури, валидиране, изпращане по мрежата, обработка на входящи фактури и архивиране, вградени в съществуващата ви система, а не на нейно място.

Задълженията и кога влизат в сила

Европа преминава от PDF фактури към структурирани, машинночетими фактури по график, различен за всяка държава, преди пакета на ЕС „ДДС в цифровата ера" (ViDA), който ще уеднакви всичко това. Датите, които в момента движат проектите:

  • Германия: получаването на структурирани електронни фактури е задължително от 1 януари 2025 г. Издаването става задължително от 1 януари 2027 г. за предприятия с оборот над 800 000 €, а от 1 януари 2028 г. за всички останали. На практика форматите са XRechnung (чист XML) и ZUGFeRD 2.x (хибриден PDF с вграден XML), като и двата съответстват на EN 16931.
  • Франция: получаването, както и издаването за големите и средните компании, от 1 септември 2026 г.; издаването за МСП от 1 септември 2027 г. Изпращането минава през регистрирани платформи, а общият хибриден формат е Factur-X.
  • Белгия: задължително електронно фактуриране B2B чрез Peppol от 1 януари 2026 г., а за 2028 г. е планирано електронно отчитане по модел с пет участника (five-corner).
  • Полша: KSeF, националната платформа за клиъринг, със собствена XML схема и собствен график.
  • Италия: SdI и FatturaPA, в действие от 2019 г. и все още най-строгият модел на клиъринг в ЕС.
  • Испания: Verifactu и задълженията за фактуриране по закона Crea y Crece, които се въвеждат успоредно с регионалните системи TicketBAI.

Ако продавате в няколко от тези държави, нямате един проект. Имате една архитектура и няколко адаптера по държави и разликата между това да подходите така или не е разликата между една интеграция и пет.

Къде всъщност се провалят проектите

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

Грешките при валидиране излизат наяве твърде късно. Отхвърлената фактура е неплатена фактура. Валидирането трябва да се прави преди изпращането, спрямо актуалната схема и актуалните бизнес правила на държавата, като грешките стигат до човек, който може да реагира, а не до лог файл.

Входящите фактури са по-трудни от изходящите. Всички планират издаването и забравят, че от датата за получаване трябва да приемат структурирани фактури от всеки доставчик, във всеки съответстващ формат, и да ги вкарват в задълженията към доставчици, без някой да отваря всяка една.

Номерация и идемпотентност. Повторните опити, изтичането на времето за връзка и сривовете на платформите са нормални. Фактура, изпратена два пъти под два номера, е данъчен проблем, а не софтуерен. Това трябва да е наред от самото начало.

Какво създаваме

Оценка и избор на формат

Кратък проект (обикновено една до две седмици), в който разглеждаме как реално се издават фактурите ви, кои задължения ви засягат и кога и какви са реалистичните ви възможности. Резултатът е писмена препоръка: кои формати ви трябват, дали достъпът до Peppol да е чрез доставчик или чрез собствена точка за достъп, какво трябва да се промени в изходната ви система и колко струва.

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

Генериране на фактури и мапинг

Изграждаме слоя за съпоставяне на вашите изходни данни с изискваните синтаксиси (UBL и CII по EN 16931, XRechnung, ZUGFeRD 2.x, Factur-X, FatturaPA, KSeF XML), като документираме как се извежда всяко поле, така че да го проследят и одиторът, и финансовият ви екип. Когато изходната система изобщо не може да даде задължително поле, казваме го рано и проектираме как да се събира, вместо да измисляме стойност по подразбиране.

Валидиране преди изпращане

Валидиране по схема, бизнес правила по Schematron и проверки според държавата се изпълняват, преди нещо да напусне вашата среда. Грешките отиват в опашка, за която отговаря конкретен човек, със съобщение, което казва кое поле не е минало проверката и защо, а не с трасиране на стека.

Връзка с мрежата

Свързване с точка за достъп до Peppol, чрез утвърден доставчик или чрез собствена точка, според обема и нужната ви степен на контрол. За държавите с модел на клиъринг интегрираме директно с националната платформа (KSeF, SdI, френската екосистема от PDP), включително работата със сертификати и удостоверяването, които всяка от тези платформи прави по свой начин.

Обработка на входящи фактури

Приемане, валидиране и уеднаквяване на фактурите от доставчици в едно вътрешно представяне, съпоставяне с поръчките за покупка и приемо-предавателните документи, когато такива има, и подаването им в процеса ви за задълженията към доставчици. Обикновено оттук идва възвръщаемостта на проекта, защото отпада ръчното въвеждане, което никой никога не е измервал.

Архивиране и одитна следа

Съхранение на оригиналния структуриран документ в съответствие с изискванията, във вид и за срок, които отговарят на германските GoBD, италианското conservazione sostitutiva или съответните правила там, където работите, с тестван, а не предполагаем начин за извличане.

Системи, с които интегрираме

SAP ECC и S/4HANA, Microsoft Dynamics 365 и Business Central, Odoo, NetSuite, Sage, Infor, Xero, интерфейси към DATEV и (най-често) собствена или силно променена система, която е в центъра на работата на бизнеса и няма да бъде подменена заради едно законово задължение. Работим с .NET, Java, PHP, Python, Node.js и, когато това е, което имаме пред себе си, с по-стари стекове.

Ако управлявате онлайн платформа за търговия (marketplace), абонаментна платформа или система за таксуване, която издава фактури програмно и в голям обем, това е точно случаят, за който сме създадени: фактурата се генерира от вашия код, следователно и съответствието трябва да живее във вашия код.

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

Не продаваме софтуер за фактуриране и не сме счетоводна програма. Ако сте малка фирма и търсите инструмент, който издава фактури според изискванията, купете си такъв: DATEV, sevDesk, Lexware и още дузина други го правят добре и струват частица от цената на интеграционен проект.

Елате при нас, когато фактурата се издава от система, която вече притежавате, когато правилата на няколко държави трябва да съжителстват или когато обемът изисква всичко да работи, без никой да го наблюдава.

Как протича проектът

Оценка, една до две седмици, на фиксирана цена, завършва с писмена препоръка и план с остойностяване.

Изграждане, обикновено шест до дванадесет седмици за първата държава, в зависимост от това колко чисти са изходните данни. Работим във вашето хранилище, по вашата стратегия за клонове, с вашия екип и оставяме тестове след себе си.

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

Преминаване и поддръжка, с наблюдавана опашка за грешки и човек, който отговаря за нея, през първото приключване на месеца и първата декларация по ДДС, защото тогава всъщност изплуват въпросите, които имат значение.

Стандарти, по които работим

EN 16931 и неговите синтактични обвързвания (UBL 2.1, UN/CEFACT CII), Peppol BIS Billing 3.0 и транспортната инфраструктура на Peppol, XRechnung и валидаторът на KoSIT, профилите на ZUGFeRD 2.x и Factur-X, FatturaPA, KSeF и предложенията по ViDA, които определят какво следва след 2030 г.

Често задавани въпроси

Кога точно германското задължение за електронно фактуриране се отнася до нас?

Получаването важи за всички германски предприятия от 1 януари 2025 г. Издаването важи от 1 януари 2027 г., ако оборотът ви за предходната година е надхвърлил 800 000 €, и от 1 януари 2028 г. в останалите случаи. Задължението обхваща вътрешните B2B сделки; режимът за трансграничното и B2C фактурирането е различен и си струва да го потвърдите с данъчния си консултант.

Каква е разликата между XRechnung и ZUGFeRD?

XRechnung е чист XML, определен от германския публичен сектор и задължителен за фактури към публични органи. ZUGFeRD 2.x е хибрид: документ PDF/A-3 със същите структурирани данни, вградени в него, така че човек може да прочете PDF файла, а машина да прочете XML. И двата формата съответстват на EN 16931. В търговската B2B практика в Германия се предпочита ZUGFeRD; много купувачи приемат и двата.

Нужна ли ни е собствена точка за достъп до Peppol?

Обикновено не. Повечето компании се свързват чрез съществуващ доставчик на точка за достъп, което е по-евтино и по-бързо. Собствена точка има смисъл при голям обем, когато ви трябва контрол над транспортния слой или когато предоставяте услуги по фактуриране на други.

Можете ли да работите със сегашния ни доставчик на електронно фактуриране?

Да, и често това е правилният модел: доставчикът поема изпращането и членството в мрежата, а ние изграждаме всичко между вашата система и неговото API: мапинга, валидирането, повторните опити, обработката на грешки и съгласуването.

Какво става с фактурите, които не минат валидирането?

Отиват в опашка с разбираемо обяснение кое поле кое правило е нарушило. Проектираме тази опашка внимателно, защото през първите месеци след пускането тя е най-използваната част от системата, а лошо направената превръща проекта за съответствие в постоянен ръчен процес.

Как избягвате двойното изпращане на една и съща фактура?

Със стабилен ключ за идемпотентност, изведен от идентичността на фактурата ви и пренасян през всеки повторен опит, плюс журнал на изпращанията, който е меродавен за това какво е изпратено. Всеки повторен опит използва първоначалния идентификатор, а не генерира нов.

Как да започнем

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

Свържете се с нас, за да заявите оценка на готовността ви за електронно фактуриране.

Свързани услуги

Готови ли сте да започнете с тази услуга?

Свържете се с нас
← Обратно към всички услуги