Автоматизиране на съответствието с ДДС в ЕС с облачен счетоводен API

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

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

Това разграничение определя всичко долу.

Какво всъщност означава „автоматизиране на ДДС в ЕС“

За една платформа, която продава в множество държави от ЕС, автоматизацията на ДДС е верига от зависими решения:

Дали клиентът е B2B или B2C и къде се намира той?
Ставката на коя държава се прилага, в коя данъчна категория и към датата на фактурата?
Доставката с обратно начисляване (reverse charge) ли е, декларирана през OSS, декларирана през IOSS или вътрешна?
Дали електронният пазар се счита за доставчик по закон (deemed supplier), или търговецът?
Какви доказателства подкрепят всеки от тези отговори и могат ли те да бъдат възпроизведени на по-късен етап?

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

Облачният счетоводен API е естественото място за съхранение на тази следа, тъй като той вече пази фактурата, записа в счетоводната книга и насрещната страна. Nordlet е създаден около тази идея: неизменяема (immutable) двустранно счетоводна книга, ДДС логика по държави, VIES валидация и генериране на i.SAF регистри - всичко това достъпно през единадесет REST интерфейса с типизирани SDK-та и уебхукове (webhooks). API-ят не е тънък слой върху счетоводството. Той е системата за регистриране на самото решение.

Трите възможности на API, които носят основната тежест

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

1. Съдържание на ставките и данъчни категории, обвързани с дата. Ставките се променят. Категориите се променят. Намалените ставки се добавят и премахват. Работещият подход, както твърди разработчикът на Sage в своите насоки относно реформата на ДДС в ЕС и счетоводните API, е да се мапират артикулите към данъчни категории, а след това данъчните категории да се обвържат с кодове по държави, придружени от дати на влизане в сила. Хардкодването на ставка за всеки артикул поотделно за всяка държава е антипатернът, който незабележимо трупа грешки, докато промяна в ставката не счупи нещо година по-късно.

2. Валидация на ДДС номер с плавно деградиране на услугата (graceful degradation). VIES е каноничният източник за трансгранична B2B валидация. Той също така е периодично ненадежден. Разумните реализации кешират валидациите с кратък TTL (време за живот на кеша), правят повторни опити при грешка и насочват неясните случаи към опашка за преглед, вместо да блокират продажбата. Схващането, че VIES трябва да връща синхронен успешен отговор за всяка транзакция, е начинът, по който платформите сами си причиняват сривове.

3. Заснемане на доказателства и неизменяемост. Всяко решение за ДДС трябва да съхранява своите входящи данни: сигнали за местоположението на клиента, ДДС номер и времеви щат на валидацията, данъчна категория, версия на таблицата със ставки, приложим режим (вътрешен, OSS, IOSS, обратно начисляване) и роля на пазара. Този запис трябва да издържи на промени в ставките и редакции в конфигурацията. Една неизменяема счетоводна книга със заключване на периоди, което Nordlet прилага на ниво API, означава, че затворен месец не може тихо да бъде пренаписан, за да изглежда един бъдещ одит по-пригледен.

Тези три възможности са абсолютният минимум. Всичко останало, включително подаването на OSS декларации, генерирането на i.SAF и съгласуването (reconciliation), се надгражда върху тях.

Моделиране на решението за ДДС, а не само на ставката

Най-често срещаният проблем при вграденото счетоводство е третирането на данъчното поле във фактурата като резултат от обичайно търсене. То не е такова. То е резултат от малък граф на решенията и именно този граф трябва да бъде съхранен.

Работещ модел:

Класифициране на насрещната страна. B2B или B2C. При B2B правете справка с VIES за валидност на ДДС номера и запазвайте отговора, включително времевия щат и статуса. При B2C изисквайте поне два сигнала за местоположение: адрес за фактуриране, IP адрес или геолокация, както и държава на платежното средство, когато е налично.
Определяне на мястото на доставка. При дигиталните услуги ДДС следва местоположението на клиента, а не на доставчика. При стоките правилата се различават в зависимост от мястото на тръгване и местоназначението на пратката. API-ят трябва да маркира всеки ред от фактурата с изчисленото място на доставка и използваните сигнали.
Избор на режим. Вътрешен, OSS (трансгранични B2C в рамките на ЕС), IOSS (внос с ниска стойност) или обратно начисляване. Логиката за праговете, по-специално прагът от 10 000 евро за трансгранични B2C продажби на дигитални услуги, трябва да се изчислява на база пълтящ прозорец (rolling window), а не само за текущата фактура изолирано.
Определяне на ставката. Направете справка за ставката на съответната държава за съответната данъчна категория към датата на фактурата. Съхранете използваната версия на таблицата със ставки.
Записване в счетоводната книга. Създайте двустранно счетоводно записване с дължим ДДС, разпределен по държави и режими, така че OSS справките и вътрешните ДДС декларации да могат да се генерират без повторно изчисляване на данните.

Всяка стъпка трябва да бъде достъпна за наблюдение през API. Уебхуковете като sale_invoice.paid позволяват на достъпните надолу по веригата системи да реагират на промени в състоянието без нужда от периодично поллинг запитване (polling). Идемпотентните ключове (idempotency keys) предотвратяват дублирани счетоводни записи, когато повторен опит заради мрежов срив се случи в неподходящия момент. Нито едно от двете не е екзотично, но и двете са задължителни при мащаб на ниво платформа.

OSS, IOSS и прагът от 10 000 евро

За софтуера като услуга (SaaS) и дигиталните услуги практичетият проблем с автоматизацията е OSS. Доставчик, който извършва трансгранични B2C продажби в рамките на ЕС, прилага ставката на своята собствена държава, докато прагът от 10 000 евро не бъде надвишен през текущата или предходната календарна година, след което прилага ставката на държавата членка на клиента и отчита тримесечно през OSS. Практическите указания относно съответствието с ДДС за SaaS и дигитални услуги разглеждат това като проблем с потока от данни (data pipeline), а не като проблем с регистрацията.

Потокът от данни, който счетоводният API трябва да поддържа:

Проследяване на трансграничните B2C приходи спрямо прага на база пълтящ прозорец (rolling basis) за всяка календарна година.
Автоматично превключване на определянето на ставката от родната държава към държавата на местоназначение при надвишаване на прага, без да се преизчисляват с назад дата минали фактури.
Групиране на транзакциите по държава членка, режим и валута за тримесечната OSS декларация.
Нормализиране на сумите в евро по правилния валутен курс към датата за OSS отчитане.
Експортиране на готовия за деклариране набор от данни във формат, който подаващата система или услуга за деклариране може да обработи.

Nordlet се справя с това чрез ДДС логика по държави в счетоводната книга и справки, които групират по режим и държава членка: OSS декларациите се изчисляват директно от самите фактури, като се отчитат корекции за минали периоди, а прагът от 10 000 евро се проследява автоматично. Декларацията се извлича от счетоводната книга, вместо да се възстановява от нулата всяко тримесечие. Това е смисълът от поставянето на графа за решения вътре в счетоводната система, а не в отделна електронна таблица.

IOSS следва същата структура за внос с ниска стойност, но с различен набор от прагове и различна декларация.

Потоците при пазарите и платформите са отделна категория

Трезирането на една платформа (marketplace) като обикновен B2C канал е моментът, в който изненадващо много реализации се провалят. В много сценарии в ЕС платформата се счита за доставчик по закон (deemed supplier) и носи отговорност за събирането и внесяването на ДДС. Собственото счетоводство на търговеца трябва да отразява факта, че платформата, а не крайният клиент, е релевантната за ДДС насрещна страна по тези транзакции.

Това е мястото, където вграденият счетоводен API доказва стойността си. В момента на продажбата платформата знае дали е действала като законов доставчик (deemed supplier). Този факт трябва да бъде записан във фактурата и пренесен в счетоводната книга, така че счетоводните книги на търговеца да не дублират ДДС, който платформата вече е оглавила. Предаването на индикатори за данъчната роля през API и отразяването им в отчетите е разликата между чисти счетоводни книги и справка за съгласуване, която никога не излиза напълно.

За платформите, изградени върху Nordlet, това е заложено по подразбиране: фактурите носят vatScheme (включително marketplace_deemed) и флаг deemedSupplier, а модулът за разрешаване на третирането (treatment resolver) връща приложимия режим заедно с неговото правно основание съгласно Директива 2006/112/EO. Съчетано с поддръжката на множество компании, счетоводството на платформата и счетоводството на търговеца могат да съществуват под един и същ API, с различни компании и различни роли, без изтичане на ДДС записи помежду им.

Какво променя ViDA и какво остава същото

Директивата „ДДС в дигиталната ера“ (ViDA) променя същността на автоматизацията от „изчисли и запиши“ към „изчисли, запиши и предай“. Електронното фактуриране и отчетността в близко до реално време пред данъчните органи стават част от потока от данни. Това не заменя счетоводния API. То прави структурираните данни за фактурите в счетоводния API източника, който се отразява огледално в шлюза за отчетност.

Две практични последствия:

Метаданните на фактурите трябва да бъдат по-богати, отколкото позволяват повечето стари схеми. Полетата по Peppol BIS 3.0, структурираното разпределение на ДДС по редове и идентификаторите на режимите трябва да бъдат основни елементи в счетоводния API, а не добавени като бележки свободен текст.
Счетоводният документ и декларираният документ трябва да бъдат в синхрон. Ако бъде издадено кредитно известие, шлюзът за отчетност трябва да види корекцията със същите идентификатори. Неизменяемите счетоводни книги и ясната родова линия на документите правят това лесно. Разхлабеното счетоводство го прави мъчително.

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

Кратко сравнение на подходите за автоматизация

Подход	Доказателства за решението за ДДС	Обработка на OSS/IOSS	Моделиране на ролята на платформата (marketplace)	Подходящо за вградени платформи
Ръчно счетоводство с електронни таблици	Слаби, възстановени впоследствие	Ръчно, предразположено към грешки	Обикновено се пренебрегва	Слабо
Стар счетоводен софтуер с допълнителен данъчен модул	Частични, често извън счетоводната книга	Поддържано, но изолирано	Ограничено	Слабо до умерено
Общ счетоводен API (тип Xero, QuickBooks)	Зависи от дисциплината на интеграцията	Варира според пазара и добавката	Не е публично потвърдено за потоци с прехвърлено задължение в контекста на ЕС	Умерено
Nordlet (ориентиран към API, с фокус върху ЕС)	Неизменяема счетоводна книга, данъчни метаданни за всяка фактура, заключване на периоди	Нативно ДДС по държави, i.SAF, VIES, групиране готово за OSS	Основна функционалност: `vatScheme`, `deemedSupplier` за всяка фактура	Силно

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

Какво да изградите първо, ако започвате сега

Ако екип изгражда вградена автоматизация на ДДС в ЕС върху облачен счетоводен API, последователността, която обикновено спестява най-много преработка:

Моделирайте насрещната страна и нейните сигнали за държава преди всичко останало. Всяко следващо решение зависи от това. Съхранявайте сигналите, а не само изведената държава.
Изградете слоя за данъчни категории. Мапирайте продуктите и услугите към категории. Мапирайте категориите към кодове по държави. Никога не мапирайте продукти директно към ставки.
Свържете VIES валидацията с кеширане и опашка за преглед. Не позволявайте на наличността на VIES да блокира вашия процес на плащане (checkout).
Генерирайте и консумирайте уебхукове за промени в състоянието на фактурите. Използвайте идепотентни ключове при всяко записване.
Заключвайте периодите веднага щом приключат. Прилагайте това на ниво API, а не чрез вътрешни правила.
Извличайте OSS декларациите от счетоводната книга. Ако декларацията се нуждае от отделна електронна таблица, счетоводната книга не носи достатъчно метаданни.
Едва тогава добавете електронно фактуриране и интеграция с шлюза за отчетност. Данните нагоре по веригата трябва да бъдат правилни на първо място.

Повечето от тези стъпки са еднократни инвестиции, които тихо се отплащат всяко тримесечие. Неограничената тестова среда (sandbox company) е най-евтиното място за доказване на последователността от край до край.

FAQ

Дали VIES валидацията е достатъчна, за да докаже, че една B2B продажба е правилно неначислена с ДДС?

Не сама по себе си. VIES потвърждава, че един ДДС номер е валиден в даден момент от времето. Записът, защитим при одит, включва също така времевия щат на проверката, полезния товар (payload) от отговора, декларираната от клиента държава и доказателствата, че стоките или услугите са били доставени на това регистрирано по ДДС лице. Съхранявайте всичко това спрямо фактурата.

Може ли платформата да разчита на електронния пазар (marketplace) да поеме ДДС и да пропусне собствената си логика?

Само за конкретните транзакции, при които пазарът се счита за доставчик по закон (deemed supplier) съгласно правилата на ЕС. Счетоводството на търговеца все пак трябва да отразява тези транзакции коректно, а всички продажби извън този обхват, включително директните продажби и B2B потоците, остават отговорност на търговеца. По-безопасният подход по подразбиране е да се моделира ролята изрично за всяка транзакция.

Колко често ДДС ставките в ЕС действително се променят, за да е от значение?

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

каква е разликата между OSS и IOSS на практика?

OSS обхваща трансгранични B2C продажби на стоки и дигитални услуги в рамките на ЕС, отчитани тримесечно чрез една държава членка. IOSS обхваща вноса с ниска стойност в ЕС, обикновено потребителски стоки под 150 евро. И двете се извличат от едни и същи счетоводни данни, ако счетоводната книга маркира всяка транзакция с нейния режим.

Означава ли неизменяемата счетоводна книга (immutable ledger), че корекциите са невъзможни?

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