Nordlet

← Blog

Contabilitate încorporată: Dezvoltare internă sau achiziție pentru marketplace-uri

O listă de cerințe, un model de costuri cu ipoteze clare și condițiile în care fiecare opțiune este corectă.

Nordlet Team · · 9 min de citire

Fiecare marketplace ajunge să își construiască propriul registru contabil (ledger) la un moment dat. Singura întrebare este dacă acesta este construit în mod deliberat, ca un sistem cu controale stricte, sau accidental, ca o coloană balance în care scriu trei servicii și în care nimeni nu are încredere sută la sută.

Acest articol este despre cum să faci această alegere în mod conștient. Acesta detaliază ce implică de fapt munca respectivă, cum să îi estimezi costurile fără a te amăgi și condițiile specifice în care dezvoltarea internă reprezintă răspunsul corect - pentru că uneori chiar așa este.

Ce înseamnă „contabilitate încorporată” în acest context

Contabilitatea încorporată (embedded accounting) înseamnă că evidența contabilă se află direct în interiorul produsului tău, nu într-o aplicație separată pe care o deschide cineva în mod independent. Software-ul tău înregistrează operațiunile pe măsură ce evenimentele se produc, utilizatorii tăi văd exact ceea ce le prezintă interfața ta și nimeni nu mai exportă un fișier Excel către un contabil la sfârșitul lunii.

Pentru un marketplace, acest lucru acoperă, cel puțin: plățile încasate de la cumpărători, sumele datorate vânzătorilor, comisioanele câștigate, comisioanele de procesare a plăților, TVA-ul aferent comisioanelor tale și cel aferent tranzacției de bază, rambursările (refunds), refuzurile de plată (chargebacks), reținerile de garanție (reserves), plățile către vânzători (payouts) și reconcilierea tuturor acestor elemente cu un extras bancar sau cu un furnizor de servicii de plată.

Ce construiești de fapt atunci când alegi dezvoltarea internă

Registrul contabil propriu-zis reprezintă doar o mică parte. Echipele estimează în mod constant doar primul element și abia ulterior le descoperă pe celelalte.

Componentă Ce presupune
Jurnal și conturi Înregistrări duble validate (balanced entries), plan de conturi, tipuri de conturi, solduri de deschidere
Imutabilitate Stocare doar cu adăugare (append-only), flux de stornare și corectare, fără editări directe în rând
Controlul perioadelor Închidere, blocare, respingere a înregistrărilor întârziate, redeschidere controlată cu pistă de audit (audit trail)
Idempotență Chei de unicitate, stocare a răspunsurilor anterioare, detectare a coliziunilor pe payload-uri modificate
Gestionarea sumelor Aritmetică exactă cu zecimale sau unități monetare subunitare (minor-unit), coduri de valută, cursuri valurale și sursa acestora, conturi de rotunjire
Motor de TVA Cote per țară cu date de valabilitate, locul prestării, taxare inversă, reguli de tip deemed supplier (furnizor prezumat), scutiri
Verificări ale codului de TVA Validare împotriva registrului oficial, caching, marcaje temporale, identificatori de cerere, o coadă de revizuire manuală pentru eșecuri
Documente Facturi, note de credit, numerotare secvențială fără lipsuri pe serie și an, randare PDF, livrare
Facturare electronică Formate structurate precum EN 16931 UBL și formate naționale specifice fiecărei țări unde sunt obligatorii
Import bancar Import de extrase sau o conexiune bancară cu consimțământ (consent), deduplicarea tranzacțiilor deja importate
Reconciliere Reguli de potrivire, punctaj, potriviri parțiale, excepții care pot fi rezolvate de un operator uman
Plăți către terți (Payouts) Generare de fișiere de plată, grupare în loturi (batching), asocierea plăților înapoi la elementele de bază
Raportare Balanță de verificare, bilanț, cont de profit și pierdere, flux de numerar (cash flow), jurnale de TVA, vechimea soldurilor (aged debt)
Jurnale și declarații fiscale Cerințele specifice țărilor tale, în formatul acceptat de autoritatea fiscală
Audit Utilizator, acțiune, entitate și modificarea în sine, interogabilă, pentru orice mutație
Păstrare și export Păstrare timp de zece ani pentru înregistrările OSS, export complet de date, arhivă conformă

Aproximativ două dintre aceste șaptesprezece rânduri reprezintă partea pe care cele mai multe echipe și-o imaginează atunci când spun „vom construi un registru contabil”.

Calcularea onestă a costurilor

Orice cifră de aici depinde de echipa ta, așa că tratează următoarele informații ca pe o metodă, nu ca pe o ofertă fixă. Ia componentele de mai sus, atribuie fiecăreia o dimensiune în săptămâni-inginer bazată pe viteza propriei echipe și aplică apoi trei corecții pe care estimările le omit de obicei.

Prima corecție: componentele de conformitate nu sunt unice (one-time). Cotele se schimbă, plafoanele se schimbă, formatele se schimbă, iar pachetul legislativ european TVA în Era Digitală (ViDA) aduce obligații cu termene clare - modificări OSS și IOSS de la 1 ianuarie 2027, reguli extinse pentru platforme de la 1 iulie 2028, raportare digitală transfrontalieră de la 1 iulie 2030. Dezvoltarea internă înseamnă că tu ești responsabil pentru fiecare dintre aceste migrări.

A doua corecție: activitatea legată de corectitudine o depășește pe cea de funcționalități. Prima versiune gestionează fluxul ideal (happy path). Coada lungă (long tail) include rambursările efectuate după efectuarea plății către vânzător, rambursările parțiale, refuzurile de plată primite săptămâni mai târziu, rotunjirile valutare, webhook-urile duplicate și fișierele de decontare care nu se potrivesc cu propriile înregistrări. Aici este locul în care calendarul proiectului scapă de sub control.

A treia corecție: contabilul este un factor implicat (stakeholder), nu un simplu evaluator. Evidențele contabile pe care un profesionist financiar nu le va semna nu sunt finalizate, iar acest feedback sosește de obicei târziu într-un ciclu de dezvoltare.

O verificare utilă a realismului: estimează costul celei mai mici variante viabile de dezvoltare internă - registru, corecții, blocarea perioadelor, idempotență, gestionarea banilor, TVA pentru o singură țară, facturi, import bancar, reconciliere și un set de rapoarte de bază - și compară-l cu un an de utilizare a unui serviciu cu plată pe consum. Planurile publicate de Nordlet din secțiunea de prețuri pornesc de la 10 EUR pe lună, cu 3.000 de cereri incluse, și ajung până la 300 EUR pe lună pentru 200.000 de cereri. Dacă o dezvoltare internă costă doar o fracțiune dintr-un an-inginer, acesta este un argument veritabil pentru a construi intern. Dacă costă mai mulți ani-inginer, plus întreținere permanentă, comparația nu mai stă în picioare, iar discrepanța crește în fiecare an în care regulile se modifică.

Când dezvoltarea internă este cu adevărat corectă

Există trei situații, toate reale.

Registrul tău este produsul tău. Dacă construiești o platformă de plăți, un produs bancar sau un portofel digital (wallet) unde comportamentul soldului în condiții de concurență (concurrency) reprezintă elementul tău de diferențiere, registrul este esențial și ar trebui să fie al tău. Ia în considerare produsele de tip infrastructură de registru în loc de o construcție de la zero și menține contabilitatea statutară separată.

Modelul tău nu se potrivește cu niciun sistem contabil. Unele marketplace-uri au structuri de decontare cu adevărat neobișnuite - împărțiri multi-parte cu eliberare condiționată, servicii de tip escrow cu etape stadializate, politici complexe de reținere a garanțiilor. Dacă niciun produs existent nu modelează acest lucru, iar soluțiile alternative sunt mai rele decât construcția proprie, atunci dezvoltă intern.

Volumul tău face ca prețul pe consum să fie inadecvat. La rate de tranzacționare extrem de ridicate, prețul per cerere încetează să mai fie atractiv. Modelează acest aspect cu cifre reale înainte de a trage concluzii, deoarece nivelul „extrem” în acest context este mai ridicat decât ating majoritatea platformelor.

Când achiziția este opțiunea corectă

Achiziția câștigă atunci când contabilitatea este necesară, dar nu reprezintă un element de diferențiere, ceea ce este cazul cel mai des întâlnit. Nimeni nu își alege marketplace-ul pentru că înregistrările tale din jurnal sunt elegante. Clienții observă acest lucru doar atunci când evidențele sunt greșite.

Achiziția este, de asemenea, decizia corectă atunci când obligațiile tale sunt transfrontaliere. Regulile de TVA specifice fiecărei țări, păstrarea dovezilor și mandatele de facturare electronică reprezintă un flux permanent de mentenanță, iar un furnizor amortizează această muncă împărțind-o la toți clienții săi. Nordlet oferă TVA în UE per țară cu validare VIES, calculul declarațiilor OSS și IOSS, jurnale i.SAF și formatul EN 16931 UBL pentru Peppol ca parte integrantă a produsului, și nu ca pe un proiect pe care trebuie să îl planifici singur.

O cale de mijloc pe care ajung cele mai multe echipe

Răspunsul practic nu este de obicei niciuna dintre extreme. Acesta este: achiziționează registrul, construiește fluxul de lucru.

Backend-ul contabil gestionează înregistrările, tratamentul fiscal, documentele, închiderea perioadei și pista de audit. Produsul tău gestionează tot ceea ce văd utilizatorii tăi și fiecare regulă de afaceri specifică marketplace-ului tău - momentul în care fondurile sunt eliberate, politica de reținere a garanțiilor, modul în care sunt gestionate litigiile și informațiile afișate în panoul de control al vânzătorului. Apelezi API-ul contabil în momentele în care banii sunt angajați și păstrezi doar componentele care îți aparțin cu adevărat.

Această delimitare rezistă, de asemenea, mult mai bine în fața schimbărilor decât alternativele. O țară nouă adaugă o simplă configurație în loc să necesite un nou proiect. O nouă politică de plăți reprezintă codul tău, nu o solicitare trimisă unui furnizor.

Ce trebuie să decizi înainte de a te angaja într-o direcție

  1. Este registrul tău un element de diferențiere sau o obligație? Fii sincer; majoritatea sunt obligații.
  2. Câte țări ai și ce solicită fiecare dintre ele? Doar cote, sau declarații, sau jurnale, sau depunere efectivă.
  3. Care este strategia ta pentru corecturi? Rambursările efectuate după plată și refuzurile de plată întârziate sunt situațiile care scot la iveală o proiectare precară.
  4. Cine semnează bilanțul? Implică acea persoană înainte ca proiectarea să fie finalizată, nu după.
  5. Care este planul de păstrare pe zece ani? Înregistrările OSS trebuie păstrate timp de zece ani de la sfârșitul anului în care a avut loc tranzacția, iar o arhivă reprezintă un sistem întreg, nu o simplă copie de rezervă.
  6. Cum va arăta o migrare peste trei ani? În ambele direcții. Creează un export de test chiar din prima zi și asigură-te că funcționează permanent.

FAQ

Cât durează să construiești un registru contabil pentru un marketplace?

O primă versiune care înregistrează operațiuni validate poate fi pusă în funcțiune în câteva săptămâni. O versiune care gestionează rambursările efectuate după plată, refuzurile târzii de plată, rotunjirile multi-valută, webhook-urile duplicate de la furnizori, închiderea perioadei și un audit acceptat de un contabil necesită mult mai mult timp, iar întreținerea nu se termină niciodată. Estimează cea de-a doua variantă, deoarece aceasta este semnificația reală a mediului de producție.

Putem începe cu o coloană balance și să migrăm mai târziu?

Poți face asta și mulți o fac, dar ia în calcul faptul că migrarea va fi mai dificilă decât construcția inițială. Reconstituirea istoricului dintr-un sold modificabil este posibilă doar dacă ai păstrat fiecare eveniment care l-a modificat - ceea ce înseamnă, de fapt, că aveai deja un registru contabil.

Un API de contabilitate încorporată înlocuiește echipa noastră financiară?

Nu. Acesta elimină înregistrarea manuală și reconcilierea. Cu toate acestea, cineva tot trebuie să închidă luna, să revizuiască excepțiile, să ia decizii bazate pe raționament profesional și să depună declarațiile.

Ce se întâmplă cu GDPR dacă registrul contabil este imutabil?

Păstrează datele monetare și referințele pseudonimizate în înregistrările imutabile, iar detaliile cu caracter personal într-un sistem separat, cu propriul său proces de păstrare și ștergere. Imunitatea se aplică evenimentului financiar, nu fiecărui atribut asociat acestuia.

Este software-ul contabil open-source o opțiune de mijloc?

Este o opțiune reală, dar modifică natura costurilor în loc să le elimine: preiei pe cont propriu găzduirea, actualizările, localizarea pe țară și actualizările legate de conformitate. Evaluează costurile acestora înainte de a considera că economia făcută la licență reprezintă imaginea de ansamblu.

Lecturi suplimentare