Автоматизиране на ДДС отчетите по държави и VIES валидацията

Повечето грешки с ДДС в кода на дадена платформа произтичат от едно предположение: че валидният резултат от VIES означава, че можете да приложите ставка 0% (zero-rate) за продажбата. Това не е така и изграждането върху това улеснение води до отчети, които изглеждат наред, докато одитор не попита защо е приложено вътреобщностно освобождаване без доказателство за транспорт или последователен запис за мястото на изпълнение (place of supply). Разликата между „ДДС номерът е изряден“ и „тази доставка е третирана правилно“ е мястото, където повечето интеграции тихо се провалят.

Това ръководство разглежда как да автоматизирате ДДС отчетите по държави и VIES валидацията с облачен счетоводен API, използвайки счетоводния API на Nordlet като контекст за реализация. Целта е система, която улавя правилните доказателства в момента на продажбата, записва неизменни счетоводни статии и генерира готови за отчет данни, групирани по режим и държава членка, без по-късно да се преизчисляват суми в таблици.

Какво всъщност ви казва VIES и какво не

VIES е системата за обмен на информация за ДДС в ЕС (VAT Information Exchange System). Когато подадете код на държава и ДДС номер, тя прави заявка към съответната национална база данни в реално време и връща дали тази ДДС информация е валидна или невалидна. Това е целият обхват. Системата потвърждава, че номерът е регистриран и, когато държавата членка го поддържа, е активиран за търговия в рамките на ЕС.

Тя не установява правото на освобождаване на вътреобщностна доставка. Европейската комисия е категорична по този въпрос. Валидният отговор от VIES е едно от доказателствата наред с други. Все пак трябва да потвърдите, че клиентът е действителният получател, че доставката отговаря на условията за вътреобщностна, че съществуват доказателства за транспорт или експедиция и че фактурата съдържа изискуемия текст за самоначисляване (reverse-charge).

Така първото проектно решение е структурно: пазете VIES статуса и ДДС третирането в отделни полета. Никога не свързвайте директно viesStatus: valid с zeroRated: true. В момента, в който слеете тези две понятия, губите способността си да защитите дадено третиране, когато доказателствата бъдат поставени под съмнение.

Предпоставки преди написването на интеграционния код

Преди да бъде извикан който и да е ендпойнт (endpoint), дефинирайте обхвата на това, което отчитате. Тази част е рутинна, но пропускането ѝ излиза скъпо.

• Държавите, в които бизнесът е установен или разполага с постоянни обекти
• Държавите, в които има валидни ДДС регистрации
• Дали продава стоки, услуги, електронни услуги или смесени доставки
• Дали транзакциите са B2B, B2C или и двете
• Дали използва местни регистрации, OSS, IOSS, обратна чардж процедура (reverse charge) или правила за фиктивен доставчик от електронен пазар (marketplace deemed-supplier)
• Какви изходи трябва да произвежда API: данни за местни отчети, OSS/IOSS данни, дневници на продажбите като литовския i.SAF, само счетоводни записвания или пакети (payloads) за външен доставчик на декларации

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

Не заложете твърдо (hard-code) и само по една ДДС ставка на държава. ЕС има стандартни, намалени, свръхнамалени, паркинг ставки, нулеви ставки и специфични за продуктите третирования, като те се променят. Надеждният източник за даден продукт в определена държава членка е данъчната администрация на тази страна, като TEDB на Комисията предлага общ преглед за различните държави. Записвайте източника и версията зад всяко решение за ставка, така че последващо обновяване на таблицата със ставки да не променя незабележимо начина, по който изглежда старата транзакция.

Моделиране на данъчното решение, а не само на ставката

Ядрото на една устойчива интеграция е слой от данъчни категории (tax-categories), разположен между продуктите и ставките. Свържете продуктите с категории, категориите с приложимите за съответната държава данъчни кодове, а тях със ставки и режими с валидност от определена дата:

продукт/услуга
    → данъчна категория
    → специфичен за държавата данъчен код
    → ставка и третиране с валидност от дата

Несигурният подход, който води до отклонения в отчетите, е продукт SKU → 21% ДДС. Един и същ продукт има различни ставки в различните държави, а дадена ставка може да се промени в средата на отчетния период. Насоките на самата Nordlet относно съответствието с ДДС в ЕС и облачния счетоводен API препоръчват именно това категоризиране, вместо обвързването на продуктите директно с проценти.

Вашата таксономия на данъчните категории трябва да бъде стабилна и вътрешна: стоки със стандартна ставка, стоки с намалена ставка, електронно доставени услуги, обикновени услуги, освободена доставка, доставка с нулеска ставка (zero-rated), вътреобщностно B2B самоначисляване, вътреобщностна дистанционна продажба, IOSS внос, транзакция с фиктивен доставчик. Всичко надолу по веригата зависи от тази таксономия.

VIES валидацията като асинхронен работен процес за доказателства

Официалната услуга VIES предоставя SOAP/WSDL интерфейс, приемащ двубуквен код на държава и ДДС номер. Нейните документирани ограничения са от значение за обработката на грешки: невалидни входни данни, глобални лимити и лимити за паралелни заявки на държавите членки, недостъпност на услугата, недостъпност на националната база данни и изтичане на времето за изчакване (timeouts). Третирайте ги като отделни резултати, а не като един общ кошер с „грешки“.

Работен процес, който издържа на натоварване и одит, изглежда по следния начин:

1. Нормализирайте ДДС номера: преобразувайте префикса в главни букви, премахнете позволените интервали или пунктуация и запазете отделно първоначално въведената от потребителя стойност.
2. Валидирайте локално кода на държавата и формата на номера, преди да правите мрежово повикване.
3. Изпратете нормализирания номер към VIES.
4. Съхранете нормализирания номер, времевите отметки на заявката и отговора, състоянието valid/invalid/not-processed (валиден/невалиден/необработен), суровия отговор, евентуалната грешка в услугата, идентификаторите на клиента и фактурата, както и решението на системата.
5. Кеширайте успешните резултати за определен и документиран период.
6. Повтаряйте неуспешните технически заявки с нарастващо закъснение (backoff).
7. Насочвайте неразрешените или противоречиви случаи към ръчна проверка.
8. Извършвайте повторна валидация, когато кешираният резултат е остарял или преди транзакция, при която доказателството е от съществено значение.

Nordlet проверява ДДС номера в ЕС при добавяне на клиент и го проверява отново преди фактуриране, когато предишният резултат е остарял – поведение, което е желателно да репликирате независимо дали проверката се извършва в платформата или във вашия собствен код.

Критичното правило: не правете плащането (checkout) синхронно с VIES. Прекъсването на услугата не означава невалиден номер. Ако VIES отговори с timeout по време на продажба, задръжте транзакцията за проверка или ѝ задайте временно състояние. Блокирането на плащането заради наличността на услугата на Европейската комисия генерира заявки към поддръжката, а погрешното класифициране на лоялен клиент като невалиден е още по-лошо.

Разделяне на статуса на валидация от данъчното третиране

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

{
  "viesStatus": "valid",
  "vatTreatment": "intra_eu_b2b_reverse_charge",
  "evidenceStatus": "reviewed",
  "placeOfSupply": "DE"
}

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

Създаване на неизменно ДДС решение в момента на фактуриране

Когато фактурата бъде създадена, запишете пълното решение заедно с нея, а не само крайната ставка:

фактура
  ├─ данъчна категория по ред
  ├─ място на изпълнение
  ├─ ДДС режим
  ├─ ставка за съответната държава
  ├─ версия на таблицата със ставки
  ├─ препратка към VIES доказателство
  ├─ препратки към доказателства за местоположение
  ├─ препратка към правно основание
  └─ флагове за ролята на електронния пазар

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

Счетоводната книга на Nordlet е неизменна (immutable), така че корекциите се извършват чрез нови записвания като кредитни известия или сторниращи статии, вместо чрез редактиране на приключени записи. Изградете софтуерната си архитектура около този модел, дори ако хранилището ви технически позволява презаписване. Редактирането на затворена фактура разрушава връзката между първоначалното подаване и корекцията, което е точно проследимостта, която един одитор търси.

Записвания, уебхукове (webhooks) и идемпотентност

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

Дебит Вземания от клиенти / клиринг на плащания
    Кредит Приходи
    Кредит ДДС за плащане - DE - вътрешен

Вътреобщностната B2B продажба със самоначисляване отчита приходи без изходен ДДС и с препратка към доказателството за самоначисляване. Точният индивидуален сметкоплан е ваш избор; важното е отчетите да поддържат прикачени към всяко записване измерения: държава членка, режим, данъчна категория, ставка, период, изходна фактура и проследимост на корекциите.

Управлявайте промените в състоянието чрез уебхукове, вместо с периодни проверки (polling). Nordlet изпраща събития като sale_invoice.paid, подписва съобщенията и повтаря неуспешните опити с нарастващо закъснение. Осигурете на всяко записване детерминиран ключ за идемпотентност (idempotency key):

sale:{platform_order_id}:invoice:{invoice_version}

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

Групиране за OSS и генериране на готови за отчет експорти

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

Декларацията по Съюзния режим разделя доставките по държава членка на потребление и прави разлика между услуги от държавата членка на идентификация, услуги от други постоянни обекти и стоки, изпратени от различни държави членки. Тя отчита данъчните основи и ДДС сумите поотделно за стандартни и намалени ставки. Освободените и освободените с право на данъчен кредит (zero-rated) доставки изобщо не влизат в OSS декларацията.

Няколко оперативни подробности, които затрудняват мнозина:

• Периодите по Съюзния и извънсъюзния OSS режим са тримесечни, а по IOSS – месечни. Декларациите и плащанията са дължими до края на следващия месец.
• Нулева декларация (nil return) се изисква за всеки период, дори когато не са извършени съответните доставки. Генерирайте списък с периоди (checklist) и създавайте автоматично нулеви декларации.
• OSS декларациите се изготвят в евро, като се използва референтният курс на ЕЦБ от последния ден на данъчния период, когато е необходимо преобразуване. Съхранявайте изходната валута, валутния курс, датата на курса, преобразуваната сума и метода.

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

Бъдете прецизни относно това какво предоставя API тук. Nordlet изчислява OSS и IOSS декларации от фактурите и счетоводната книга, включително корекции за минали периоди, подготвя пакети за местни отчети за Литва (FR0600), Германия (UStVA) и Полша (JPK_V7M), както и генерира готови за VMI i.SAF дневници за Литва. Това са готови за отчитане данни. Едно API повикване не подава ДДС декларацията на всяка държава през всеки национален портал и никоя декларация не се подава към орган от ваше име. Поддържайте счетоводството, генерирането на отчети, експорта, подаването към портите и потвърждението на плащането като отделни състояния в системата си. Ръководството за ДДС двигателя в ЕС документира кои случаи разрешава двигателят и къде се задействат неговите предупреждения.

Заключване на периода

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

Чести грешки и как да ги избягвате

Грешка	Причина	Начин на предотвратяване
Третиране на валиден VIES резултат като достатъчен за нулева ставка	VIES не установява права за освобождаване	Съхранявайте доказателства за клиента, доставката, транспорта и фактурата заедно с резултата
Третиране на невалиден резултат като доказателство за липса на регистрация	Номерът може да не е активиран за търговия в ЕС или базата данни да закъснява	Разграничавайте невалидни, необработени и технически грешки; насочвайте споровете към преглед
Синхронно изпълнение на плащането с VIES	Лимити за паралелни заявки, времеви изчаквания, прекъсвания	Асинхронна валидация, краткотрайно кеширане, нарастващо закъснение, временни състояния
Кеширане на резултатите за неопределено време	Статусите на регистрация и активация се променят	Съхранявайте времеви отметки и срок на годност; проверявайте отново преди фактуриране при остарели данни
Обвързване на продуктите директно с ДДС проценти	Ставките и освобождаванията зависят от държавата и датата	Продукт към категория, към код на държава, към ставка с валидност от дата
Реконструиране на OSS от таблици	Общите суми пропущат корекции, държави на експедиция, доказателства	Извличане от неизменната счетоводна книга с измерения на всяка статия
Включване на услуги от местни постоянни обекти в OSS	Определени услуги принадлежат към местния отчет	Моделирайте обектите отделно, насочвайте по режим преди агрегирането
Пропускане на нулеви отчети	OSS изисква декларация за всеки период	Генерирайте списък и създавайте автоматично нулеви декларации
Редактиране на затворени фактури за корекция	Унищожава връзката между подаването и корекцията	Използвайте кредитни известия и сторниращи статии в по-късен период

Откъде да започнете

Ако стартирахме тази интеграция утре, щяхме да изградим слоя с данъчни категории и записа за ДДС решение, преди да докоснем нито един ендпойнт за отчети. Направете таксономията стабилна, свържете продуктите с категориите и се уверете, че записът за решение улавя суровите сигнали от държавата плюс причината за избора на място на изпълнение. Всичко останало – VIES, записвания, OSS групиране, експорт – зависи от правилния избор на този модел.

След това бихме свързали VIES като асинхронен етап за събиране на доказателства с четири отделни състояния и бихме го тествали срещу тестова компания (sandbox company) с фиктивни данни за сложните случаи (timeout, необработени резултати, несъвпадащи префикси), преди да го доближим до производствена среда. Изброените по-горе грешки са почти напълно избегми, ако моделът от данни носи доказателствата и отчетните измерения още от първото счетоводно записване.

FAQ

Означава ли валиден VIES отговор, че мога да приложа 0% ставка за B2B продажба в ЕС?

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

Трябва ли VIES валидацията да блокира завършването на поръчката (checkout)?

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

Може ли облачен счетоводен API да подава моите ДДС декларации автоматично?

Той може да генерира готови за отчитане данни, групирани по режим и държава членка, изчислени от неизменната счетоводна книга с включени корекции. Дали съществува и подаване през съответната национална портална система зависи от продукта и държавата. Nordlet изчислява OSS и IOSS декларации, подготвя пакети за местни отчети за Литва, Германия и Полша и генерира готови за VMI i.SAF дневници за Литва, но не подава нищо към данъчна администрация от ваше име. Третирайте счетоводството, генерирането на отчети, експорта, подаването към портите и плащането като отделни състояния, вместо да приемате, че едно повикване подава всичко навсякъде.

Как да се справя с корекции след заключване на период?

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

Допълнително четене

• Автоматизиране на съответствието с ДДС в ЕС с облачен счетоводен API
• Интегриране на облачен счетоводен API в SaaS платформа
• Проверка на ДДС номер (VIES), Европейска комисия