Bonul electronic în Egipt: ce cere de fapt de la casa unui restaurant

Bonul electronic nu e un modul pe care îl atașezi la final. Cere articole codificate, dispozitive înregistrate, transmiteri semnate și date de vânzări fără goluri — și le cere înainte de termenul tău, nu după.

2026-09-249 min de citit

Majoritatea proprietarilor de restaurante întâlnesc bonul electronic cum întâlnești o groapă în asfalt: brusc și cu un termen atașat. Instinctul e să-l tratezi ca pe o hârțogărie — treaba contabilului sau un modul pe care furnizorul îl activează.

Nu este așa. Este un set de cerințe privind modul în care casa ta înregistrează o vânzare, iar o casă care înregistrează neglijent nu devine conformă adăugându-i ceva deasupra.

Întâi: cele două sisteme nu sunt același lucru

Egiptul are două sisteme înrudite, dar distincte, iar confuzia dintre ele costă săptămâni.

Factura electronică (الفاتورة الإلكترونية) acoperă tranzacțiile dintre firme. Furnizorul îți emite una. Dacă facturezi un catering unei companii, emiți una.
Bonul electronic (الإيصال الإلكتروني) acoperă vânzarea către consumatorul final la casă — un client care mănâncă și plătește. El guvernează marea majoritate a operațiunilor unui restaurant.

Un restaurant cu livrare, cu linie de catering și cu sală atinge probabil ambele. Stabilește ce flux de venit ține de care înainte să ceri o ofertă, fiindcă răspunsul schimbă ce cumperi.

Ce cere de fapt sistemul

Fără jargon, cere patru lucruri.

1. Un dispozitiv înregistrat. Fiecare punct de casă se înregistrează la administrația fiscală prin portalul dedicat, iar dispozitivele trec printr-o verificare tehnică și de securitate. Un dispozitiv neînregistrat sau respins nu e o chestiune de configurare — e o casă care nu poate emite legal.

2. O transmitere semnată. Bonurile se semnează electronic — semnătură sau sigiliu — ca administrația să poată stabili că înregistrarea vine într-adevăr de la tine și nu a fost modificată. Cineva trebuie să dețină acea credențială, să știe unde este păstrată fizic și ce se întâmplă când expiră.

3. Articole codificate. Acesta e pasul care ia oamenii prin surprindere. Fiecare articol vândut trebuie să poarte un cod recunoscut de administrație, legat de tratamentul fiscal corect. Un meniu cu o sută optzeci de poziții, fiecare cu cod și clasificare, nu e treaba unei după-amiezi — și e ceea ce transformă cel mai des un termen într-o criză.

4. Transmitere aproape în timp real. Bonul pleacă în momentul vânzării, iar exemplarul clientului poartă un cod QR cu care înregistrarea poate fi verificată în sistemul administrației.

Poziția pe care nimeni nu o bugetează: codificarea meniului

Dacă iei un singur lucru practic din articolul acesta, ia-l pe acesta.

Începe codificarea articolelor înaintea oricărui alt pas. Este singura parte a cărei durată e dată de meniul tău și nu de calendarul furnizorului, și este partea care la final nu poate fi grăbită.

Reguli care scutesc de refaceri:

Codifică articolul pe care îl vinzi, nu ingredientul pe care îl cumperi. O porție de pui la grătar este un articol vandabil cu tratament fiscal. Puiul din depozit este stoc, și nu despre el raportează un bon.
Decide întâi unde stă taxa de serviciu. Nu e impozit, nu se comportă ca un impozit, iar un bon care le amestecă produce o cifră pe care nimeni nu o mai poate reconcilia.
Meniurile combinate și opțiunile cer o gândire separată. O băutură la format mare, o garnitură schimbată, o ofertă de meniu: toate trebuie să se rezolve în ceva codificabil. Lasă-le pe ultima săptămână și vei descoperi excepțiile în cel mai prost moment.
Fă-o o singură dată și centralizat. Dacă ai trei locații cu trei meniuri ușor diferite, acesta este momentul care te costă — sau cel în care în sfârșit le unifici.

Ce cere de la casa ta, indiferent de marcă

Aceste cerințe supraviețuiesc oricărui termen și funcționează ca test atunci când alegi un sistem:

Cerință	De ce contează
Numerotare secvențială fără goluri	Un număr lipsă e primul lucru căutat la un control și cel mai greu de explicat
Anulări și retururi ca înregistrări inverse	O vânzare anulată trebuie să lase o urmă care o stornează. Un sistem care șterge distruge secvența
Impozit și serviciu pe linii separate	Lucruri diferite, destinații diferite. Amestecate, nu mai pot fi reparate în aval
Metodă de plată înregistrată per vânzare	Numerarul, cardul și fiecare portofel au nevoie de linia lor, altfel reconcilierea nu mai bate cu banca
Export complet, nu un PDF	Contabilul are nevoie de detaliu ca date. Un PDF lunar e o fotografie a datelor tale
Date fiscale pe punct de lucru	Cotele, numerele de înregistrare și decizia cu sau fără taxă inclusă țin de locație, nu de firmă

Observă că niciuna nu este o „funcție de bon electronic”. Sunt evidențe bune obișnuite — și exact acesta e miezul. Conformitatea nu e un modul, ci consecința unei case care a fost onestă cu privire la ce s-a întâmplat.

Întrebarea la care demonstrația nu răspunde: ce se întâmplă când cade linia?

Transmiterea e aproape în timp real. Conexiunea din Egipt nu este.

Acest decalaj transformă un sistem conform într-o coadă de clienți nervoși și merită apăsat înainte de semnătură:

Casa continuă să vândă când cade conexiunea, sau se oprește?
Bonurile netrimise sunt puse în coadă și transmise automat la revenirea liniei, sau le reintroduce cineva?
Dacă o transmitere este respinsă, te anunță sistemul? Poate fi corectată și retrimisă — sau eșuează tăcut și apare la sfârșit de lună?
Când înlocuiești o casă defectă, cine reînregistrează dispozitivul și cât așteaptă restaurantul?

Un furnizor care a rulat asta într-un restaurant real răspunde repede și concret. Cel care a citit doar specificația răspunde abstract. Diferența se aude.

GoSufra este construit pentru această formă de problemă: casa continuă să preia comenzi când cade conexiunea, iar coada recuperează după aceea; fiecare vânzare poartă metoda reală de plată; numerotarea este secvențială prin construcție; detaliul de vânzări și taxe se exportă ca date, nu ca PDF lunar. Aceasta este fundația pe care trebuie să stea orice integrare de transmitere — iar un sistem care nu poate produce date curate, secvențiale și exportabile nu devine conform pentru că i se înșurubează un conector.

Ce de făcut luna aceasta

Stabilește-ți poziția reală. Ce etapă ți se aplică, după mărime și activitate? Întreabă contabilul și confirmă direct la administrația fiscală, nu pe pagina comercială a unui furnizor. Administrația are o linie la 16395 și o adresă la eReceipt.hd@eta.gov.eg.
Pornește codificarea articolelor. Azi, nu după alegerea furnizorului.
Închide chestiunea taxei de serviciu cu contabilul, în scris.
Numără punctele de casă și confirmă că fiecare poate fi înregistrat.
Decide cine deține semnătura electronică — și unde stă fizic credențiala.
Testează exportul actual. Poți produce chiar acum o lună completă de vânzări detaliate și secvențiale, ca date? Dacă nu, aceea e problema reală, cu obligație sau fără.

O precauție necesară

Etapele, pragurile, termenele și sancțiunile acestui sistem s-au mutat în repetate rânduri pe măsură ce implementarea s-a lărgit și sunt administrate de Autoritatea Fiscală egipteană în temeiul legislației de procedură fiscală — nu de furnizorii de software, noi incluși. Nimic din acest articol nu stabilește ce se aplică restaurantului tău la o dată anume.

Două lucruri, însă, pot fi începute în siguranță acum. Codificarea meniului este muncă pe care o vei face sub orice versiune a regulilor. Iar o casă care înregistrează fiecare vânzare în secvență, cu metoda reală de plată și cu taxa separată de serviciu, este singurul punct de plecare din care conformitatea este o setare, nu o reconstrucție.