Les exigences égyptiennes en matière de reçus électroniques en 2026
dépendent de trois enregistrements

En 2026, le test de périmètre repose sur votre numéro d'immatriculation, pas sur votre chiffre d'affaires

Une entreprise est tenue d'émettre des reçus électroniques lorsque son numéro d'immatriculation fiscale figure dans une décision d'obligation publiée par le chef de l'Egyptian Tax Authority (ETA), et aucun chiffre d'affaires ne répond à cette question.

Le système de reçus électroniques constitue la moitié B2C de l'infrastructure fiscale numérique de l'Égypte. Le système de facturation électronique, qui repose sur la décision ministérielle n° 188 de 2020, couvre les ventes entre entreprises et vers les organismes publics. Le système de reçus électroniques couvre les ventes au consommateur final et repose sur les articles 35 et 37 de la loi n° 206 de 2020 sur les procédures fiscales unifiées, mise en œuvre par la décision ministérielle n° 230 de 2022, telle que modifiée par la décision n° 38 de 2024. Un détaillant ayant des clients grossistes exécute les deux, et une même transaction n'appartient jamais aux deux.

L'obligation est arrivée par phases, chacune étant une décision distincte accompagnée d'une liste nominative de contribuables et d'une date de début. Les dernières étapes programmées se présentaient ainsi :

Les dates et numéros de décision ci-dessus sont ceux du calendrier du ministre et des décisions de l'ETA, tels que résumés dans ce tableau phase par phase de Nassef & Partners International, un cabinet comptable égyptien. Deux détails importent plus que les dates. La date de début qui lie une entreprise est celle de la décision qui la nomme, laquelle peut différer de la date du calendrier du ministre. Et un segment dont la date programmée est passée n'est pas automatiquement hors périmètre, car l'enregistrement volontaire a toujours été ouvert. La vérification pratique consiste à rechercher le numéro d'immatriculation dans l'interrogation des obligations de l'ETA, à conserver le résultat avec la date de la vérification, et à la répéter après une fusion, une réorganisation de succursale ou une nouvelle décision.

Le chiffre de 150 000 EGP qui circule dans les résumés des exigences égyptiennes en matière de reçus électroniques n'est pas un seuil de périmètre. C'est une règle d'identification de l'acheteur au sein de Receipt v1.2 : lorsque l'acheteur est une personne physique et que le total du reçu atteint 150 000 EGP ou plus, le numéro d'identité nationale et le nom de l'acheteur deviennent des champs obligatoires. Le seuil d'assujettissement à la TVA, et le plafond de 20 millions d'EGP pour le régime simplifié en vertu de la loi n° 6 de 2025, répondent encore à d'autres questions. Ni l'un ni l'autre ne remplace la liste des obligations.

Un numéro d'immatriculation à la TVA fait entrer une entreprise dans le système fiscal. Il ne la fait pas entrer dans une décision relative aux reçus électroniques.

La conséquence d’être nommé est concrète. Ne pas émettre de reçu, ou en émettre un sans les données exigées par l’article 37, expose l’entreprise à une amende de 20 000 à 100 000 EGP en vertu de l’article 71. Depuis janvier 2025, un coût n’est également déductible que s’il est justifié par une facture ou un reçu électronique, ce qui pousse la même règle du côté des achats du grand livre. Et la condition d’adhésion au régime fiscal simplifié inclut désormais la participation aux systèmes électroniques de l’ETA, de sorte que l’obligation de reçu électronique suit une entreprise jusque dans le régime censé simplifier ses déclarations.

Différents pays ont bâti la même capacité avec une architecture différente, et ce choix de conception change ce que la finance doit rapprocher. La France achemine les factures B2B via des plateformes certifiées en vertu de l’article 91 de sa loi de finances 2024, ce qui fait de la plateforme le point de contrôle. L’Égypte place la séquence et l’historique des corrections sur l’appareil du contribuable. Si vous travaillez dans les deux, le guide sur la facturation électronique en France 2026 couvre l’autre modèle.

Un reçu porte deux ensembles de champs, et un seul concerne la vente

Receipt v1.2 divise le document en données commerciales qui décrivent ce qui a été vendu et en données de contrôle qui prouvent que le document provient d’un appareil autorisé dans la bonne séquence, et les équipes financières ne capturent habituellement que les premières.

Les versions 1.0 et 1.1 du reçu sont retirées, donc la 1.2 est la base de référence pour toute intégration construite aujourd’hui. Le schéma Receipt v1.2 est public, ce qui signifie qu’il n’y a aucune excuse pour une liste de champs assemblée à partir du résumé d’un fournisseur. La couche commerciale couvre le vendeur, la succursale, les lignes d’articles et les totaux. La couche de contrôle couvre les identifiants qui rendent le reçu trouvable et la chaîne qui rend difficile d’en retirer un sans laisser de trou.

Les contrôles système méritent une lecture plus lente, car ils se comportent différemment de tout ce à quoi un comptable est habitué. L'UUID n'est pas attribué par l'administration. C'est un hachage SHA-256 de 64 caractères calculé à partir du contenu normalisé du reçu lui-même. Toute modification du contenu produit un UUID différent. Le previous UUID pointe vers le dernier document émis par le même appareil POS, de sorte que chaque caisse maintient sa propre chaîne et que seul le premier document de cet appareil peut porter une valeur vide. Lorsqu'un reçu échoue à la validation et doit être corrigé, la version corrigée conserve le previous UUID d'origine et place l'UUID rejeté dans reference old UUID, ce qui préserve un lien consultable entre les deux versions. Le dispositif CFDI du Mexique fait face à un problème d'identité comparable et le résout avec un timbre fiscal, comme l'explique le guide d'extraction des factures CFDI. La différence est que l'identifiant égyptien est dérivé d'un contenu que le contribuable peut modifier, ce qui explique précisément pourquoi les corrections le changent.

Deux autres champs ont une portée plus étroite qu'ils n'y paraissent. Le numéro de reçu est unique par succursale au sein d'une même soumission, et non à l'échelle de l'entreprise. Un groupe comptant douze succursales peut légitimement avoir un reçu numéroté 1042 dans chacune d'elles le même jour. Et l'horodatage d'émission est enregistré en UTC, tandis que l'imprimante, le caissier et le rapport Z, le rapport de clôture de fin de journée imprimé depuis la caisse, travaillent tous à l'heure locale du Caire. Ces deux points semblent anodins jusqu'à ce que le rapprochement de fin de mois utilise le mauvais comme clé.

La règle relative à l'acheteur est le champ le plus souvent mal interprété. Le type d'acheteur B exige le numéro d'enregistrement de l'entreprise et son nom. Le type d'acheteur P exige le numéro d'identité national et le nom uniquement lorsque le total atteint 150 000 EGP, et ce seuil s'applique aux reçus en version 1.2 et ultérieure ; les versions antérieures utilisaient 50 000 EGP. Un reçu de café de 240 EGP nécessite un total, un mode de paiement et une succursale, pas le numéro d'identité national du client.

L'UUID est une empreinte du contenu du reçu, pas un numéro de facture. Modifiez un seul caractère et l'empreinte change avec lui.

Quatre conditions doivent être remplies avant qu'un appareil puisse soumettre

Un appareil qui n'a pas été enregistré et activé peut enregistrer une vente correcte toute la journée et ne rien produire qu'ETA acceptera ; la liste de contrôle d'intégration fait donc partie de l'histoire du rapprochement plutôt que d'un projet informatique distinct.

La première condition est une succursale enregistrée et toujours active à la date d'émission ; l'administration valide les dates d'activité des succursales et bloquera l'émission depuis une succursale fermée. La deuxième est un point de vente enregistré auprès de cette succursale, avec un numéro de série unique par appareil et lié au numéro d'enregistrement du vendeur avant l'émission de tout reçu. La troisième est le tag B2C sur le profil du contribuable, car un contribuable qui en est dépourvu ne peut soumettre de reçus sur aucun canal. La quatrième est le codage des articles selon GS1 ou le système égyptien des biens et services (EGS), avec les codes que le contribuable est réellement autorisé à utiliser. Une caisse qui envoie des descriptions internes au lieu des codes autorisés échouera à la validation après que l'argent a été encaissé.

Le cas de l'ERP a son propre piège. La FAQ d'ETA sur les points de vente permet d'enregistrer un système comptable mono-succursale comme un seul POS logiciel. Lorsqu'un ERP central émet pour plusieurs points de vente, chaque point de vente doit être enregistré comme un POS distinct afin que le reçu identifie la bonne source. Les équipes qui enregistrent l'ERP une seule fois et le laissent émettre pour toutes les succursales se retrouvent avec des reçus commercialement corrects mais structurellement erronés, et l'incohérence ne devient visible que lorsqu'un rapprochement au niveau de la succursale ne retrouve pas ses propres ventes.

Le jeton de soumission ajoute une condition qui continue de s'appliquer après la mise en production. Il identifie le contribuable propriétaire du POS, et les données de l'émetteur et de l'appareil sur le reçu doivent correspondre à cette autorisation. Après qu'ETA modifie une autorisation, et en particulier après l'approbation d'une demande de soumission tardive, l'appareil doit s'authentifier à nouveau avant que l'autorisation mise à jour n'apparaisse dans son jeton. Une file de reçus qui échoue sans cesse sans raison visible est souvent due à un jeton obsolète plutôt qu'à une charge utile défectueuse.

Trois horloges déterminent si un reçu existe

Trois délais différents régissent un reçu électronique égyptien, et ils expirent à des échelles totalement différentes : 24 heures pour soumettre, 30 jours pour récupérer un reçu tardif et 540 jours pour émettre un retour sur la vente d'origine.

La règle normale est la soumission au moment de la vente et au plus tard 24 heures après l'émission. Un reçu plus ancien n'est pas perdu, mais il ne peut pas être simplement poussé par le canal normal. Le contribuable introduit d'abord une demande de soumission tardive, indique un motif et travaille dans un quota fixé par l'ETA par an ; la demande a aussi une période d'activité limitée, et l'appareil doit se réauthentifier pour que son jeton porte l'autorisation. Les reçus soumis dans le cadre d'une demande approuvée conservent leur date d'émission d'origine. La documentation de l'ETA sur l'émission des reçus traite la limite extérieure de cette fenêtre comme un paramètre de configuration plutôt qu'un nombre fixe, et les orientations fiscales égyptiennes la décrivent actuellement comme 30 jours.

Les retours fonctionnent sur l'horloge la plus longue. Un reçu de retour doit référencer l'UUID du reçu de vente d'origine, et il peut être émis jusqu'à 540 jours après cette vente. Un retour ne peut pas dépasser le montant d'origine, et plusieurs retours partiels ne peuvent pas totaliser plus que l'original. Il n'existe pas d'équivalent d'une écriture de crédit générique sans document source : un retour sans la référence ne remplace pas le document exigé.

Les limites de lot appartiennent à la même section car elles déterminent ce qu'une file hors ligne peut faire. Une seule soumission peut contenir jusqu'à 500 reçus ou 1,5 Mo, et un seul reçu peut contenir jusqu'à 300 lignes, avec une moyenne d'environ 10 lignes. Un magasin très fréquenté qui perd la connectivité pendant une journée peut dépasser la limite par soumission avant de dépasser la limite de temps, et une file qui réessaie le même lot surdimensionné continuera d'échouer pendant que l'horloge tourne. Le piège plus discret est qu'un lot est validé comme une unité : la FAQ POS de l'ETA indique qu'un seul reçu invalide rend tout le lot invalide, donc une seule ligne mal saisie peut bloquer tous les documents envoyés avec elle.

L'horloge subtile est le calendrier. Comme l'horodatage d'émission est stocké en UTC et que l'Égypte fonctionne en UTC+2, ou UTC+3 entre fin avril et fin octobre en vertu de la loi n° 24 de 2023, un reçu encaissé à 01h30 heure locale le 1er mai est enregistré à 22h30 UTC le 30 avril. Ce reçu appartient à mai dans le rapport Z et à avril dans tout regroupement construit à partir de l'horodatage. Les dates de changement 2026 pour Le Caire sont le 24 avril et le 30 octobre, ce qui décale le décalage d'une heure deux fois par an. Pour un magasin ouvert après minuit, les derniers reçus d'un mois peuvent faire basculer une journée entière de chiffre d'affaires dans la période précédente.

L'horloge de 24 heures mesure le temps écoulé. Elle ne détermine pas à quel mois appartient le reçu.

Le contrôle mensuel rapproche trois populations, et l'ordre compte

Le rapprochement de fin de mois compare trois populations de transactions, et non trois totaux, car chaque enregistrement a été produit par un processus différent pour un objectif différent et chacun peut être correct en interne tout en divergeant des deux autres.

Quatre rôles interviennent dans cette comparaison. Le caissier ou l'opérateur POS émet le reçu, imprime la copie client et traite le retour au comptoir. Le comptable enregistre les ventes et retours du jour, rattache le rapport Z au grand livre et dépose la déclaration de TVA mensuelle, qui pour la plupart des contribuables est mensuelle et pour les entreprises relevant de la loi n° 6 de 2025 est trimestrielle. L'administrateur ERP gère le mappage des succursales et des appareils, les codes d'articles et l'intégration de soumission, y compris la file d'attente hors ligne. L'utilisateur du portail ETA enregistre les succursales et les appareils, détient les identifiants client et dépose les demandes de soumission tardive. Dans une entreprise à succursale unique, deux de ces rôles sont souvent tenus par la même personne, c'est pourquoi le fichier doit être lisible par quelqu'un qui ne l'a pas créé.

L'ordre de comparaison relève d'un jugement, et l'ordre utile est celui des conséquences plutôt que celui des montants. Commencez par la population ETA, car un document manquant constitue une exposition juridique et la fenêtre de régularisation se referme pendant que vous travaillez. Comparez ensuite POS et ERP au niveau de la succursale et de l'appareil, car c'est là que se logera une erreur comptable. Puis examinez les reçus individuels, car la correspondance ligne par ligne sur un mois est coûteuse et doit être réservée aux exceptions produites par les deux premières étapes.

Comparez les nombres avant les valeurs, et comparez-les au niveau le plus granulaire que les données permettent. Un total d'entreprise qui concorde peut masquer une succursale en déficit et une autre en excédent du même montant, et une succursale en déficit le matin et en excédent le soir peut clôturer parfaitement alors que les transactions sous-jacentes n'ont jamais correspondu. Compter les documents, puis faire correspondre les valeurs, puis vérifier l'identité est plus lent sur le papier et plus rapide en pratique, car chaque étape élimine une classe de causes.

Un total d'entreprise qui concorde peut masquer une succursale en déficit et une autre en excédent.

Les groupes multi-magasins doivent construire la comparaison à partir de la même discipline d'extraction, quel que soit le POS utilisé par chaque magasin. Le flux de travail permettant de transformer plusieurs systèmes de caisse en un résumé des ventes comparable est décrit dans cinq magasins sur trois systèmes POS, un résumé des ventes comparable, et la même conception de colonnes s'applique au volet ETA du contrôle.

Cinq façons dont les enregistrements cessent de concorder

Presque chaque écart à trois voies remonte à l'un des cinq problèmes d'identité ou de timing, et chacun nécessite une correction différente, c'est pourquoi les traiter tous comme des « erreurs de comptabilité » fait perdre le mois.

1. L'UUID imprimé n'est pas l'UUID détenu par ETA

Lorsqu'un reçu échoue à la validation et que le contribuable corrige le contenu, le reçu corrigé obtient un nouvel UUID car l'UUID est recalculé à partir du contenu modifié. La copie imprimée du client porte encore l'ancien. Une équipe financière qui effectue la correspondance sur l'UUID imprimé trouvera un document dont ETA n'a aucune trace, conclura que le reçu n'a jamais été soumis et soumettra un doublon. L'élément qui résout ce problème est le previous UUID de référence sur la version acceptée : il renvoie au document rejeté, et la version acceptée conserve le previous UUID du document rejeté afin que la chaîne de l'appareil reste intacte.

2. La clé sur laquelle vous effectuez la jointure n'est pas unique

Les numéros de reçu sont uniques par succursale au sein d'une soumission, pas à l'échelle de l'entreprise, de sorte qu'un groupe de douze succursales peut avoir douze reçus valides numérotés 1042 le même jour. Une jointure sur le seul numéro de reçu associera un reçu à la mauvaise succursale et produira un écart qui n'est qu'un artefact de la jointure. La même défaillance apparaît un niveau plus bas lorsqu'un ERP central émet pour plusieurs points de vente sous un seul enregistrement : le numéro de série de l'appareil sur le reçu pointe vers un POS que le propre enregistrement de la succursale ne reconnaît pas, même si la vente et le montant sont corrects.

3. Un retour est enregistré comme une vente négative

ETA traite un retour comme un type de document à part entière, référençant la vente d'origine par UUID, et le rapprochement doit le compter comme un document. Un système comptable qui comptabilise un remboursement comme une ligne négative dans le journal des ventes compense correctement la valeur mais laisse le nombre de documents erroné. Le mois affiche alors un chiffre d'affaires concordant et un nombre de documents inférieur du nombre de retours, ce qui est facilement diagnostiqué à tort comme des soumissions manquantes. Récupérez les reçus de retour et faites-les correspondre par UUID de référence avant tout ajustement.

4. La file hors ligne a franchi la limite des 24 heures

Les directives égyptiennes autorisent l'émission d'un reçu hors ligne, conservé localement et envoyé au retour de la connectivité, la fenêtre de 24 heures étant la durée maximale autorisée. Une file bloquée pendant une journée laisse le POS et l'ERP détenant des ventes qu'ETA n'a jamais reçues : la comparaison POS-ERP concorde parfaitement et la comparaison avec ETA est incomplète. Le correctif n'est pas une correction comptable. C'est une demande de soumission tardive, une ré-authentification et un moniteur de file qui alerte bien avant la fermeture de la fenêtre plutôt qu'après.

5. La limite mensuelle a changé

Si le rapprochement regroupe les documents ETA par leur date d'émission UTC et regroupe le POS par date commerciale, les deux populations divergeront à chaque fin de mois de tout ce qui a été enregistré après minuit local. L'écart est faible, reproductible et ne se résorbe jamais, ce qui est la signature d'une erreur de regroupement plutôt que d'un document manquant. Convertissez un côté vers l'autre avant de comparer, et indiquez dans le dossier de travail la base de date utilisée par le fichier. La même conversion s'applique lors des changements d'heure d'avril et d'octobre, où le décalage varie d'une heure.

Les colonnes qui rendent le contrôle reproductible

Un contrôle reproductible commence par une ligne par document et un ensemble de colonnes fixe, car la clé de jointure doit être choisie avant l'ouverture du premier fichier, et non après l'apparition du premier écart.

Les documents qui alimentent ce tableau ne sont pas prestigieux. Il s'agit du rapport de clôture journalière de la succursale imprimé depuis le POS, de l'écran de statut de validation enregistré en PDF ou en capture d'écran, des images de reçus remises par les succursales et le personnel, et de l'export du journal depuis le système comptable. Depuis janvier 2025, le volet achats s'est développé, car un coût doit être justifié par une facture ou un reçu électronique pour être déductible, ce qui signifie que les employés soumettent désormais des images de reçus qui étaient auparavant jetées.

Les clés ne sont pas équivalentes, et l'ordre dans lequel les essayer est fixe. L'UUID est la plus forte car l'administration le considère comme unique dans tout le système. Code de succursale plus numéro de série de l'appareil plus numéro de reçu constitue le repli fiable, et c'est la clé à utiliser lorsque l'UUID est illisible ou a changé. Heure d'émission plus montant est la plus faible et ne doit que confirmer une correspondance établie par une autre clé, car une journée de vente au détail regorge de reçus du même montant.

Une fois le tableau créé, trois contrôles arithmétiques s'exécutent au sein d'un même reçu, sans avoir besoin d'un autre document. Le total des lignes doit correspondre au total imprimé, moins toute remise au niveau du reçu. Pour une ligne taxée au taux standard de 14 %, la taxe incluse dans un total TTC s'obtient en multipliant le total par 14 et en le divisant par 114 ; un chiffre qui ne correspond pas signifie que la ligne est exonérée, taxée à un autre taux, ou mal saisie. Et la répartition par mode de paiement doit correspondre au même total. Ces contrôles détectent un chiffre mal lu avant qu'il ne devienne un écart de rapprochement, ce qui coûte moins cher que de le découvrir un mois plus tard.

Où l'extraction intervient, et où elle s'arrête

L'étape d'extraction est la seule partie de ce flux de travail qu'un outil documentaire peut prendre en charge, et c'est en précisant quelle partie il prend en charge que le reste du contrôle devient fiable.

Le travail consiste ici à capturer des champs sur un grand nombre de documents sans mise en page fixe. Une succursale imprime son rapport de clôture journalière depuis le POS qu'elle utilise, un responsable fiscal enregistre l'écran de validation au format PDF, et le personnel photographie les reçus sur trois téléphones différents. ImageToTable.ai utilise l'Extraction de colonnes personnalisées : vous saisissez les noms de colonnes souhaités, tels que « Receipt UUID », « Branch Code », « Device Serial », « Issue Date (UTC) », « Total » et « Tax Amount », et l'IA localise chaque valeur sur chaque document selon ce qu'elle signifie plutôt que selon une position fixe dans un modèle. Les noms de colonnes que vous saisissez deviennent les en-têtes du tableau de sortie.

Le traitement par lots est ce qui rend cette approche praticable en fin de mois. Importez en une seule fois un mois de rapports de succursale, d'exports de statut et d'images de reçus, et le résultat est un seul tableur avec une ligne par document. Les dates et les montants sont normalisés à la sortie, de sorte qu'une date imprimée 30/04/2026 et une date imprimée 2026-04-30 arrivent dans le même format et peuvent être triées et additionnées.

Les colonnes calculées gèrent l'arithmétique qui relève d'un seul reçu. Une colonne nommée « VAT at 14% (Total × 14 ÷ 114) » renvoie la taxe implicite du montant brut pour chaque ligne, et une colonne qui soustrait la somme des montants de ligne du total imprimé renvoie zéro pour un reçu correct et un nombre pour un reçu mal lu. Ce que les colonnes calculées ne font pas, c'est comparer des champs entre deux documents différents ; la jointure POS-ERP et le calcul d'écart restent donc un travail de tableur après l'export.

Le Review Mode avec localisation Bbox est le contrôle des champs qui portent la décision. Cliquez sur une cellule et la page d'origine met en évidence la ligne dont provient la valeur, de sorte qu'un UUID, un montant ou une date d'émission peut être vérifié par rapport à l'image sans avoir à le chercher. Cela importe surtout pour l'UUID, qui compte 64 caractères hexadécimaux et constitue le champ le moins indulgent du tableau. Lire un hachage de 64 caractères sur une impression thermique n'est pas fiable ; traitez donc le triplet succursale, appareil, numéro de reçu et montant comme clé primaire et utilisez l'UUID comme contre-vérification. Lorsqu'un reçu imprimé porte le QR code ETA, le lien de partage qu'il contient renvoie vers la page de détail du reçu et constitue une meilleure source pour l'identifiant que la chaîne imprimée.

Les limites méritent d'être énoncées clairement, car un dossier de conformité bâti sur un outil surestimé est pire que pas de dossier du tout. L'outil n'émet, ne signe, ne valide ni ne soumet de reçus à l'ETA, et il ne détermine pas si une entreprise est concernée. Il ne vous dit pas si un reçu est juridiquement valide, et il ne peut pas voir le registre de l'administration sauf si quelqu'un lui fournit un document contenant ce registre. Il ne joint pas de lui-même la population POS à la population ERP. Ce qu'il élimine, ce sont la ressaisie et le feuilletage qui produisent des erreurs silencieuses, et il laisse le jugement : quel écart est une correction, quel écart est une soumission manquante, et quel écart est un défaut de mapping.

La précision est élevée sur les tableaux imprimés, avec jusqu'à 99 % de reconnaissance et 5 à 10 secondes par page contre environ 3 minutes de saisie manuelle, mais les images de reçus ne sont pas toutes des tableaux imprimés. Le papier thermique s'estompe, les plis traversent le total et les photos prises au téléphone arrivent avec un angle. Échantillonnez le lot avant de faire confiance à l'ensemble du fichier, et vérifiez les champs qui déterminent le résultat plutôt que tous les champs de la même manière. La logique des champs elle-même est familière dans d'autres juridictions ; si vous capturez déjà des reçus de TVA pour une autre administration fiscale, le guide des champs des reçus de TVA au Royaume-Uni montre la même approche par colonnes avec un ensemble de règles différent, et la méthode plus large est décrite dans le guide complet de l'extraction des données de reçus.

FAQ

Toute entreprise égyptienne doit-elle émettre des e-reçus en 2026 ?

Non. L'obligation suit les listes nominatives des décisions de l'ETA relatives aux e-reçus, et non une règle générale applicable à toutes les entreprises assujetties à la TVA. Recherchez le numéro d'immatriculation dans la consultation des obligations de l'ETA et conservez le résultat daté. Une entreprise dont le segment a déjà dépassé sa date mais qui n'est pas nommée ne doit pas présumer qu'elle est hors du système, car l'inscription volontaire est possible et une décision ultérieure peut l'y ajouter.

Un e-reçu imprimé est-il valable sans le QR code ?

Le contribuable est tenu de générer un QR code et de l'apposer sur le reçu imprimé, et le code renvoie à la page de détail du reçu à l'aide de l'UUID et de l'heure d'émission en UTC. Une impression sans ce code est une copie client incomplète, même si le document sous-jacent a été soumis correctement. Pour le rapprochement, ce sont les champs imprimés et l'enregistrement accepté par l'administration qui comptent ; le QR code est le moyen pour le client d'accéder à cet enregistrement, et non la preuve que la soumission a réussi.

Que se passe-t-il si Internet tombe en panne à la caisse ?

Le reçu peut toujours être émis, conservé localement et soumis au retour de la connexion, mais la fenêtre de 24 heures continue de courir. Si la file d'attente la dépasse, les reçus nécessitent une demande de soumission tardive avant de pouvoir être acceptés, et l'appareil doit se réauthentifier pour que son jeton porte l'autorisation. Surveillez l'ancienneté de la file plutôt que sa taille, et déclenchez une alerte sur le reçu non envoyé le plus ancien.

Comment enregistrer un retour pour que le mois se rapproche correctement ?

Comme un reçu de retour distinct référençant l'UUID de la vente d'origine, et non comme une ligne négative dans le journal des ventes. Le retour ne peut pas dépasser le montant d'origine, et plusieurs retours partiels ne peuvent pas totaliser plus que l'original. Conservez le retour dans le décompte des documents et compensez-le uniquement à l'étape de la valeur, afin que le décompte des documents et le chiffre d'affaires répondent à des questions différentes.

Combien de temps les enregistrements doivent-ils être conservés ?

Les règles fiscales égyptiennes exigent généralement que les livres, registres et pièces justificatives soient conservés pendant cinq ans, et les enregistrements électroniques comptent comme enregistrements principaux. Conservez les payloads des reçus, les accusés de réception de l'administration, les erreurs de validation, les versions corrigées et le document de travail de rapprochement, pas seulement les copies clients. Confirmez la période applicable à votre entité auprès de votre conseiller fiscal égyptien, car le profil de l'entreprise peut modifier la réponse.

Cet outil peut-il soumettre des reçus à l'ETA à ma place ?

Non. La soumission, la signature et la validation se font dans l'intégration POS ou ERP qui détient les identifiants de l'appareil et la séquence. L'outil capture les données à partir des documents que vous possédez déjà, y compris les reçus imprimés, les rapports de succursale et les écrans de statut enregistrés, et les regroupe dans un seul tableau afin que les trois populations puissent être comparées. Il ne remplace pas l'intégration et ne détermine pas si un document est conforme.

Le changement utile est modeste. Une fois que les trois populations figurent dans un même tableau avec une clé déclarée et une base de date déclarée, un écart cesse d'être une discussion de fin de mois et devient une ligne à laquelle est rattachée une cause. Commencez par une succursale et un mois : extrayez le rapport de clôture journalière, l'export du grand livre et l'écran de statut, saisissez les douze colonnes une fois, et voyez combien de différences se résolvent avant que quiconque n'ouvre un portail. Faites passer un mois de reçus dans le flux de travail par colonnes et comptez combien de lignes correspondent à un seul document.