Automatizarea raportării TVA în funcție de țară și a validării VIES

Cele mai multe erori legate de TVA în codul unei platforme pornesc de la o singură presupunere: aceea că un rezultat VIES valid înseamnă că puteți aplica cota zero la vânzare. Acest lucru nu este adevărat, iar utilizarea acestei scurtături generează deconturi care par în regulă până când un auditor întreabă de ce s-a aplicat o scutire intracomunitară fără dovezi de transport sau fără o înregistrare consecventă a locului livrării. Prăpastia dintre „numărul de TVA este în regulă” și „această livrare este tratată corect” este zona în care majoritatea integrărilor eșuează discret.

Acest ghid prezintă modul de automatizare a raportării TVA pe țări și a validării VIES cu ajutorul unui API de contabilitate în cloud, utilizând API-ul de contabilitate Nordlet ca mediu de implementare. Obiectivul este un sistem care colectează dovezile corecte în momentul vânzării, înregistrează articole contabile imuabile și produce date gata de raportare, grupate pe scheme și state membre, fără a fi nevoie de reconstituirea ulterioară a totalurilor într-un tabel Excel.

Ce ne spune de fapt VIES și ce nu ne spune

VIES este sistemul de schimb de informații privind TVA al UE (EU VAT Information Exchange System). Atunci când trimiteți un cod de țară și un număr de TVA, acesta interoghează baza de date națională relevantă în timp real și returnează un status valid sau invalid pentru datele de TVA respective. Acesta este întregul său domeniu de aplicare. Sistemul confirmă doar că un număr este înregistrat și, dacă statul membru sprijină acest lucru, că este activat pentru comerțul intracomunitar.

El nu stabilește dreptul de a scuti o livrare intracomunitară. Comisia Europeană este foarte explicită în această privință. Un răspuns VIES valid reprezintă doar o probă printre altele. În continuare, trebuie să confirmați că clientul este destinatarul efectiv, că livrarea se califică drept intracomunitară, că există dovezi de transport sau expediție și că factura conține mențiunile obligatorii privind taxarea inversă.

Prin urmare, prima decizie de proiectare este una structurală: păstrați statusul VIES și tratamentul TVA în câmpuri separate. Nu legați niciodată direct viesStatus: valid de zeroRated: true. În momentul în care contopiți aceste două concepte, pierdeți capacitatea de a vă susține tratamentul fiscal atunci când dovezile sunt puse sub semnul întrebării.

Cerințe preliminare înainte de a scrie codul de integrare

Înainte de apelarea vreunui endpoint, definiți sfera a ceea ce urmează să raportați. Această etapă este plictisitoare, iar ignorarea ei este costisitoare.

• Țările în care compania este stabilită sau în care deține sedii fixe
• Țările în care deține înregistrări în scopuri de TVA
• Dacă vinde bunuri, servicii, servicii digitale sau un mix al acestora
• Dacă tranzacțiile sunt de tip B2B, B2C sau ambele
• Dacă utilizează înregistrări interne, OSS, IOSS, taxare inversă sau reguli privind persoana impozabilă considerată a fi furnizorul (deemed-supplier)
• Ce livrabile trebuie să producă API-ul: date pentru decontul intern, date pentru OSS/IOSS, jurnale de facturi precum i.SAF din Lituania, doar înregistrări în jurnalul contabil sau payload-uri pentru un furnizor extern de servicii de raportare

Acest lucru contează deoarece OSS nu absoarbe orice tranzacție. Serviciile prestate într-o țară în care compania are un sediu aparțin în general decontului intern al acelei țări, și nu decontului OSS. Modelați sediile separat de la început, altfel veți direcționa greșit aceste livrări în momentul agregării.

De asemenea, nu introduceți manual („hard-code”) o singură cotă de TVA per țară. UE are tratamente standard, reduse, super-reduse, de parcare, cu cotă zero și specifice anumitor produse, iar acestea se modifică. Sursa de încredere pentru un anumit produs dintr-un anumit stat membru este autoritatea fiscală din acea țară, baza de date TEDB a Comisiei oferind o imagine de ansamblu transfrontalieră. Înregistrați sursa și versiunea din spatele fiecărei decizii privind cota de TVA, astfel încât o actualizare ulterioară a tabelului de cote să nu rescrie în mod silențios modul în care apare o tranzacție veche.

Modelarea deciziei fiscale, nu doar a cotei de TVA

Baza unei integrări durabile o reprezintă un strat de categorii fiscale situat între produse și cote. Mappați produsele pe categorii, categoriile pe coduri fiscale specifice țării, iar apoi pe cote cu valabilitate la o anumită dată:

produs/serviciu
    → categorie fiscală
    → cod fiscal specific țării
    → cotă și tratament valabile la data respectivă

Varianta nesigură care generează discrepanțe în raportare este SKU produs → TVA 21%. Același produs are cote diferite în țări diferite, iar o cotă se poate schimba în mijlocul perioadei. Ghidul de conformitate privind TVA-ul al Nordlet recomandă exact această mapare bazată pe categorii, în loc să lege produsele direct de procente.

Taxonomia dumneavoastră pentru categoriile fiscale trebuie să fie stabilă și internă: bunuri taxate standard, bunuri taxate redus, servicii furnizate pe cale electronică, servicii obișnuite, livrări scutite, livrări cu cotă zero, taxare inversă B2B intracomunitară, vânzări la distanță intracomunitare, importuri IOSS, tranzacții cu furnizori considerați (deemed-supplier). Tot ceea ce urmează în aval se bazează pe această taxonomie.

Validarea VIES ca flux asincron de colectare a dovezilor

Serviciul oficial VIES expune o interfață SOAP/WSDL care preia un cod de țară din două litere și un număr de TVA. Erorile sale documentate contează pentru gestionarea excepțiilor: date de intrare invalide, limite de concurență globale și la nivelul statelor membre, indisponibilitatea serviciului, indisponibilitatea statului membru și expirarea timpului de așteptare (timeouts). Tratați-le ca pe rezultate distincte, nu ca pe o singură categorie de „eșec”.

Un flux care rezistă la volum mare și la audit arată astfel:

1. Normalizați ID-ul de TVA: treceți prefixul cu majuscule, eliminați spațiile sau semnele de punctuație permise și păstrați separat valoarea originală introdusă de utilizator.
2. Validați local codul de țară și structura numărului înainte de a efectua un apel de rețea.
3. Trimiteți numărul normalizat către VIES.
4. Stocați ID-ul normalizat, marcajele de timp pentru cerere și răspuns, starea de validitate (valid/invalid/neprocesat), răspunsul brut, orice eroare de sistem, ID-urile clientului și ale facturii, precum și decizia aplicației.
5. Salvați în cache rezultatele reușite pentru o perioadă definită și documentată.
6. Reîncercați erorile tehnice temporare utilizând o politică de revenire (backoff).
7. Redirecționați cazurile nerezolvate sau contradictorii către o revizuire manuală.
8. Revalidați atunci când un rezultat din cache a expirat sau înainte de o tranzacție în care proba este esențială.

Nordlet verifică un număr de TVA din UE atunci când un client este adăugat și îl reverifică înainte de facturare dacă rezultatul anterior a expirat, acesta fiind comportamentul pe care doriți să îl replicați, indiferent dacă verificarea se face în platformă sau în propriul cod.

Regula critică: nu faceți ca procesul de finalizare a comenzii (checkout) să fie sincron cu VIES. O pană de curent a serviciului nu înseamnă un număr invalid. Dacă serviciul VIES nu răspunde în timpul unei vânzări, plasați tranzacția în așteptare pentru revizuire sau atribuiți-i o stare provizorie. Blocarea finalizării comenzii din cauza disponibilității unui serviciu al Comisiei generează tichete de suport, iar clasificarea greșită a unui client bun ca fiind invalid este și mai gravă.

Separarea statusului de validare de tratamentul fiscal

Odată ce aveți un rezultat VIES, motorul de decizie are mai mult de lucru. Stocați acestea ca fiind câmpuri distincte:

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

Înainte de aplicarea unei taxări inverse sau a unei scutiri, motorul trebuie să verifice dacă clientul este în mod genuin destinatarul, dacă țara clientului și prefixul de TVA sunt coerente, dacă livrarea se califica drept intracomunitară, dacă se aplică reguli speciale privind locul livrării, dacă există dovezi de transport, dacă vânzătorul acționează în calitate de persoană impozabilă considerată furnizor și dacă factura conține mențiunile obligatorii. Un status VIES valid care nu trece niciunul dintre aceste teste suplimentare nu reprezintă o lumină verde.

Crearea unei decizii fiscale imuabile în momentul facturării

Atunci când factura este emisă, păstrați decizia completă asociată acesteia, nu doar cota finală:

factură
  ├─ categoria fiscală a liniei
  ├─ locul livrării
  ├─ schema de TVA
  ├─ cota specifică țării
  ├─ versiunea tabelului de cote
  ├─ referința la proba VIES
  ├─ referințe la probele de locație
  ├─ referința la baza legală
  └─ indicatori privind rolul în piață (marketplace-role flags)

Regulile UE privind facturarea impun detalii despre furnizor și client, numărul facturii, descrierea, baza impozabilă, cota de TVA, suma TVA-ului și orice informații privind taxarea inversă sau scutirea. Notele de credit și corecturile au nevoie de o referință clară la factura originală.

Jurnalul contabil al Nordlet este imuabil, astfel încât corecturile se fac prin noi înregistrări, cum ar fi notele de credit sau înregistrările de stornare, și nu prin modificarea unor înregistrări închise. Construiți-vă aplicația în jurul acestui model, chiar dacă stocarea dumneavoastră ar putea tehnic să suprascrie datele. Editarea unei facturi închise distruge legătura dintre declarația originală și corecție, care este exact firul pe care îl urmărește un auditor.

Înregistrări contabile, webhook-uri și idempotență

O vânzare generează înregistrări contabile în partidă dublă care păstrează atât tranzacția comercială, cât și obligația de TVA defalcată pe țară și schemă. O vânzare internă poate genera:

Debit: Clienți / clearing de plăți
    Credit: Venituri
    Credit: TVA de plată - DE - intern

O vânzare intracomunitară B2B cu taxare inversă generează venituri fără TVA colectat și o referință la proba de taxare inversă. Planul de conturi exact vă aparține; ceea ce contează este ca dimensiunile de raportare să rămână atașate fiecărei înregistrări: statul membru, schema, categoria fiscală, cota, perioada, factura sursă și istoricul corecturilor.

Declanșați schimbările de stare prin webhook-uri, și nu prin interogări periodice (polling). Nordlet emite evenimente precum sale_invoice.paid, semnează transmisiunile și reîncearcă în caz de eșec folosind o politică de revenire. Atribuiți fiecărei scrieri o cheie de idempotență deterministă:

sale:{platform_order_id}:invoice:{invoice_version}

Aplicația dumneavoastră trebuie să fie, de asemenea, idempotentă. Un webhook poate ajunge de două ori, poate sosi cu întârziere sau se poate declanșa după ce cererea inițială a reușit deja. Verificați semnăturile, înregistrați ID-urile evenimentelor, puneți în carantină evenimentele deformate, procesați-le printr-o coadă durabilă și reconciliați starea webhook-ului cu API-ul conform unui program. Dacă nu ați lucrat până acum cu webhook-uri semnate și chei de idempotență, aici se ascund cele mai subtile erori de dublă înregistrare.

Gruparea pentru OSS și generarea exporturilor gata de raportare

Pentru tranzacțiile OSS eligibile, grupați datele din jurnalul contabil pe schemă, stat membru de consum, tip de livrare, categorie de cotă, cotă, bază impozabilă, sumă TVA, stat membru de expediție sau de stabilire, monedă și perioadă de corecție.

Decontul pentru schema UE separă livrările după statul membru de consum și distinge serviciile din statul membru de identificare, serviciile din alte sedii fixe și bunurile expediate din diferite state membre. Acesta raportează separat bazele impozabile și sumele de TVA pentru cotele standard și reduse. Livrările scutite și cele cu cotă zero rămân în afara decontului OSS în întregime.

Câteva detalii operaționale care pun probleme:

• Perioadele OSS pentru Uniune și din afara Uniunii sunt trimestriale; IOSS este lunar. Deconturile și plățile sunt scadente până la sfârșitul lunii următoare.
• Este obligatorie depunerea unui decont cu valoare nulă pentru fiecare perioadă, chiar dacă nu au fost efectuate livrări relevante. Generați o listă de verificare a perioadelor și creați automat un decont cu valoare zero.
• Deconturile OSS sunt efectuate în euro, utilizând cursul de referință BCE din ultima zi a perioadei fiscale în care este necesară conversia. Stocați moneda de sursă, cursul de schimb valutar, data cursului, suma convertită și metoda.

Exporturile trebuie să provină din jurnalul contabil blocat, niciodată dintr-un tabel lateral. Totalurile din foi de calcul pierd corecturile, țările de expediție, cotele și dovezile. Un export conține perioada de raportare, schema, statul membru de consum, țara de expediție, categoria de livrare, cota, sumele impozabile și de TVA, moneda și cursul de schimb aplicat, sumele de corecție pentru perioada curentă și perioada anterioară, ID-urile facturilor sursă, referințele la notele de credit și totalurile de reconciliere.

Fiți preciși în ceea ce privește livrabilele API-ului în acest caz. Nordlet calculează deconturile OSS și IOSS pe baza facturilor și a jurnalului contabil, incluzând corecturile pentru perioadele anterioare, livrează pachete de deconturi interne pentru Lituania (FR0600), Germania (UStVA) și Polonia (JPK_V7M) și generează jurnale i.SAF pregătite pentru VMI în Lituania. Acestea sunt date gata de raportare. Un singur apel API nu depune decontul de TVA al fiecărei țări prin fiecare portal național și niciun decont nu este transmis unei autorități în numele dumneavoastră. Mențineți contabilitatea, generarea deconturilor, exportul, trimiterea către portal și confirmarea plății ca stări separate în sistemul dumneavoastră. Ghidul pentru motorul de TVA din UE documentează cazurile pe care motorul le rezolvă și momentele în care se declanșează avertismentele acestuia.

Blocarea perioadei

După revizuire și aprobare, reconciliați facturile cu înregistrările din jurnal, reconciliați soldurile de TVA din contabilitate cu setul de date al decontului, exportați decontul, înregistrați referințele de depunere și plată, apoi blocați perioada. Nordlet blochează înregistrările într-o lună blocată, inclusiv prin intermediul API-ului. Corecturile efectuate după blocare sunt trecute într-o perioadă ulterioară, cu legături explicite către documentul original și perioada de decontare afectată.

Moduri comune de eșec și cum să le evitați

Mod de eșec	De ce se întâmplă	Măsuri de mitigare
Tratarea unui rezultat VIES valid ca fiind suficient pentru cota zero	VIES nu stabilește drepturile de scutire	Pocați dovezile privind clientul, livrarea, transportul și factura alături de rezultat
Tratarea unui rezultat invalid ca dovadă a lipsei de înregistrare	Este posibil ca numărul să nu fie activat pentru comerțul intracomunitar sau baza de date să aibă întârzieri	Faceți distincția între invalid, neprocesat și eșec tehnic; direcționați litigiile către revizuire
Rularea sincronă a verificării VIES la checkout	Limite de concurență, expirări de timp (timeouts), întreruperi	Validare asincronă, cache pe termen scurt, revenire (backoff), stări provizorii
Salvarea în cache pe termen nelimitat a rezultatelor	Statusul de înregistrare și activare se modifică	Stocați marcajele de timp și expirarea; reverificați înainte de facturare dacă datele sunt vechi
Maparea directă a produselor pe procente de TVA	Cotele și scutirile depind de țară și dată	Produs la categorie, la codul țării, la cota valabilă la data respectivă
Reconstituirea OSS din tabele Excel	Totalurile omit corecturile, țările de expediție, dovezile	Derivați datele din jurnalul contabil imuabil, cu dimensiuni pe fiecare înregistrare
Includearea serviciilor sediilor interne în OSS	Anumite servicii aparțin decontului intern	Modelați sediile separat, direcționați în funcție de schemă înainte de agregare
Omiterea deconturilor nule	OSS impune un decont pentru fiecare perioadă	Generați o listă de verificare și creați automat deconturi cu valoare zero
Editarea facturilor închise pentru corecturi	Distruge legătura dintre declarație și corecție	Utilizați note de credit și înregistrări de stornare într-o perioadă ulterioară

Ce am face mai întâi

Dacă am începe această integrare mâine, am construi stratul de categorii fiscale și înregistrarea deciziei fiscale înainte de a atinge vreun endpoint de raportare. Stabilizați taxonomia, asigurați-vă că produsele sunt mapate pe categorii și asigurați-vă că înregistrarea deciziei captează semnalele brute din țară plus motivul pentru care a fost ales locul livrării. Totul a celălalt – VIES, înregistrările contabile, gruparea OSS, exportul – depinde de corectitudinea acestui model.

Apoi, am configura VIES ca o etapă asincronă de colectare a dovezilor, cu cele patru stări separate, și am rula-o pe o companie de test (sandbox) cu scenarii pentru cazurile problematice (expirări de timp, rezultate neprocesate, prefixe nepotrivite) înainte de o lăsa să se apropie de producție. Modurile de eșec menționate mai sus pot fi evitate aproape în întregime dacă modelul de date păstrează dovezile și dimensiunile de raportare încă de la prima înregistrare.

Întrebări frecvente (FAQ)

Un răspuns VIES valid înseamnă că pot aplica cota zero la o vânzare B2B intracomunitară?

Nu. VIES confirmă că un număr de TVA este înregistrat și, dacă este susținut, activat pentru comerțul intracomunitar. Dreptul de a scuti o livrare intracomunitară depinde de probe suplimentare: calitatea clientului de destinatar efectiv, dovada de transport sau expediție, locul corect al livrării și mențiunile obligatorii pe factură. Stocați rezultatul VIES ca o singură intrare, nu ca pe o decizie finală.

Ar trebui ca validarea VIES să blocheze finalizarea comenzii (checkout)?

Nu ar trebui. VIES poate depăși timpul de așteptare sau poate atinge limitele de concurență, iar o pană de curent nu este același lucru cu un număr invalid. Validați asincron, păstrați în cache rezultatele reușite pentru o perioadă documentată, reîncercați eșecurile temporare și mențineți cazurile ambigue în așteptare pentru revizuire cu o stare provizorie, în loc să eșuați vânzarea.

Poate un API de contabilitate în cloud să depună automat deconturile mele de TVA?

Acesta poate genera date gata de raportare, grupate pe scheme și state membre, calculate din jurnalul contabil imuabil, incluzând corecturile. Dacă se face și transmiterea prin fiecare portal național de depunere, acest lucru depinde de produs și de țară. Nordlet calculează deconturile OSS și IOSS, livrează pachete de deconturi interne pentru Lituania, Germania și Polonia și generează jurnale i.SAF pregătite pentru VMI în Lituania, dar nu transmite nimic către o autoritate fiscală în numele dumneavoastră. Tratați contabilitatea, generarea deconturilor, exportul, transmiterea la portal și plata ca stări separate, în loc să presupuneți că un singur apel le face pe toate peste tot.

Cum gestionez corecturile după ce o perioadă este blocată?

Înregistrați-le într-o perioadă ulterioară, cu legături explicite către documentul original și perioada de decontare afectată. Nordlet blochează noile înregistrări pentru o lună blocată, inclusiv prin intermediul API-ului, astfel încât corecturile să treacă prin note de credit sau înregistrări de stornare, și nu prin modificări directe. Acest lucru păstrează istoricul dintre declarația inițială și ajustare.

Lecturi suplimentare

• Automatizarea conformității cu TVA-ul în UE utilizând un API de contabilitate în cloud
• Integrarea unui API de contabilitate în cloud într-o platformă SaaS
• Verificarea unui număr de TVA (VIES), Comisia Europeană