2026年のエジプト電子レシート要件は
3つの記録に依存する

2026年、適用範囲の判断基準は売上高ではなく納税者登録番号です

エジプト税務当局（ETA）の長官が公表する義務決定にその納税者登録番号が記載されている場合、事業者は電子レシートを発行する義務があります。売上高の数字ではこの問いに答えられません。

電子レシート制度は、エジプトのデジタル税務インフラにおけるB2C向けの部分です。電子請求書制度は大臣決定第188号（2020年）に基づき、企業間および政府機関への販売を対象としています。電子レシート制度は最終消費者への販売を対象とし、統一税務手続法第206号（2020年）第35条および第37条に基づき、大臣決定第230号（2022年）を決定第38号（2024年）で改正した内容によって実施されています。卸売顧客を持つ小売業者は両方を運用し、同一の取引が両方に属することはありません。

義務は段階的に導入され、各段階は対象納税者のリストと開始日を添付した個別の決定でした。最後に予定された段階は次のとおりです。

上記の日付と決定番号は、エジプトの会計事務所であるNassef & Partners Internationalによるこの段階別表にまとめられているとおり、大臣のスケジュールおよびETAの決定に基づくものです。日付よりも重要な点が2つあります。事業者を拘束する開始日は、その事業者を名指しした決定に記載された日付であり、大臣のスケジュールの日付と異なることがあります。また、予定日が過ぎた区分であっても、自動的に適用範囲外になるわけではありません。任意登録は常に受け付けられてきたからです。実務上の確認方法は、ETAの義務照会で登録番号を検索し、確認日とともに結果を保存し、合併、支店再編、新たな決定の後に再確認することです。

エジプトの電子レシート要件の概要で流布しているEGP 150,000という数字は、適用範囲の閾値ではありません。これはReceipt v1.2内の購入者識別ルールです。購入者が自然人であり、レシート合計がEGP 150,000以上に達する場合、購入者の国民IDと氏名が必須項目となります。VAT登録の閾値、および法律第6号（2025年）に基づく簡易制度のEGP 2,000万の上限は、また別の問いに答えるものです。いずれも義務リストの代わりにはなりません。

VAT登録番号は事業者を税務システムに参加させますが、電子レシートの決定に参加させるものではありません。

名前が記載されることの結果は具体的です。レシートを発行しない場合、または第37条で求められるデータなしで発行した場合、事業者は第71条に基づきEGP 20,000からEGP 100,000の罰金を科される可能性があります。2025年1月以降、費用は電子インボイスまたはレシートによって裏付けられている場合にのみ控除可能となり、同じルールが帳簿の仕入側にも及んでいます。また、簡素化税制の適用条件にETA電子システムへの参加が含まれるようになったため、電子レシートの義務は、申告を簡素化するために設けられた制度にも事業者とともに付いてきます。

各国は同じ機能を異なるアーキテクチャで構築しており、その設計の選択が財務部門の照合対象を変えます。フランスは2024年財政法第91条に基づき、B2Bインボイスを認定プラットフォーム経由で処理し、プラットフォームを管理の要としています。エジプトはシーケンスと訂正履歴を納税者のデバイス上に置きます。両方の業務に関わる場合、フランス電子インボイス2026ガイドで別のモデルを確認できます。

レシートには2つのフィールドセットがあり、販売に関するものはそのうち1つだけ

Receipt v1.2は、文書を、何が販売されたかを示す商業データと、その文書が正しい順序で認可されたデバイスから発行されたことを証明する管理データに分けており、財務チームは習慣的に前者のみを取得しています。

レシートのバージョン1.0および1.1は廃止されているため、現在構築する統合にとって1.2が基準となります。Receipt v1.2スキーマは公開されているため、ベンダーの要約からフィールド一覧を作成する言い訳はありません。商業層は販売者、支店、品目行、合計を対象とします。管理層は、レシートを見つけられるようにする識別子と、隙間を残さずに1つを削除することを困難にするチェーンを対象とします。

システム管理の項目は、簿記担当者が慣れ親しんだものとは挙動が異なるため、より注意深く読む価値があります。UUIDは当局によって割り当てられるものではありません。レシート自体の正規化された内容から計算される64文字のSHA-256ハッシュです。内容が変わればUUIDも変わります。previous UUIDは同じPOSデバイスが最後に発行したドキュメントを指すため、各レジは独自のチェーンを維持し、そのデバイスの最初のドキュメントのみ空の値を持つことができます。レシートが検証に失敗して訂正が必要になった場合、訂正版は元のprevious UUIDを保持し、拒否されたUUIDをreference old UUIDに格納することで、2つのバージョン間の検索可能なリンクを維持します。メキシコのCFDI制度も同様の識別問題に直面しており、timbre fiscalで対処しています。これはCFDI請求書抽出ガイドで説明されているとおりです。違いは、エジプトの識別子が納税者が編集できる内容から導出される点であり、まさにそのために訂正によって変化するのです。

さらに2つのフィールドは、見た目よりも適用範囲が狭いものです。レシート番号は同じ提出内の支店ごとに一意であり、会社全体で一意ではありません。12の支店を持つグループでは、同じ日に各支店で1042番のレシートが正当に存在し得ます。また、発行タイムスタンプはUTCで記録されますが、プリンター、レジ係、そしてZレポート（レジから印刷される日締めレポート）はすべてカイロ現地時間で動作します。月末の照合で誤った方をキーとして使用するまでは、どちらも些細なことに見えます。

買い手ルールは最も誤読されやすい項目です。買い手タイプBは事業登録番号と名称が必要です。買い手タイプPは、合計がEGP 150,000に達する場合にのみ国民IDと名称が必要で、この閾値はバージョン1.2以降のレシートに適用されます。それより古いバージョンではEGP 50,000でした。EGP 240のカフェのレシートに必要なのは合計、支払方法、支店であり、顧客の国民IDではありません。

UUIDはレシート内容の指紋であり、請求書番号ではありません。1文字変えれば指紋も変わります。

デバイスが提出できるようになるための4つの条件

登録・有効化されていないデバイスは、一日中正しい販売を記録しても、ETAが受け付けるものは何も生成できません。そのためオンボーディングのチェックリストは、独立したITプロジェクトではなく照合の話の一部です。

第一の条件は、発行日時点で有効な登録済み支店であることです。当局は支店の有効期間を検証し、廃止された支店からの発行を停止します。第二は、その支店に対して登録されたPOSで、デバイスごとに一意のシリアル番号がレシート発行前に売り手の登録番号に紐付けられていることです。第三は納税者プロファイルのB2Cタグです。これがない納税者はどのチャネルでもレシートを提出できません。第四はGS1またはエジプト物品・サービス（EGS）システムに基づく品目コードで、納税者が実際に使用を許可されているコードであることです。許可されたコードではなく内部の説明文を送信するレジは、代金を受け取った後に検証で失敗します。

ERPのケースには独自の落とし穴があります。ETAのPOSに関するFAQでは、単一支店の会計システムを1つのソフトウェアPOSとして登録することが認められています。中央のERPが複数の販売店舗に対して発行する場合、各店舗を別々のPOSとして登録し、レシートが正しい発行元を識別できるようにする必要があります。ERPを一度だけ登録し、すべての支店に対して発行させるチームは、商業的には正しいが構造的には誤ったレシートを生み出すことになり、その不一致は支店レベルの照合で自店の売上が見つからないときに初めて明らかになります。

提出トークンは、稼働開始後も適用され続ける条件を追加します。これはPOSを所有する納税者を識別するもので、レシート上の発行者とデバイスのデータはその認可と一致していなければなりません。ETAが権限を変更した後、特に遅延申請が承認された後は、更新された権限がトークンに反映される前にデバイスが再度認証を行う必要があります。目に見える理由もなく失敗し続けるレシートのキューは、多くの場合、不正なペイロードではなく古いトークンが原因です。

レシートの存在を決める3つの時計

エジプトの電子レシートには3つの異なる期限があり、それぞれまったく異なる規模で失効します。提出まで24時間、遅延レシートの回復まで30日、元の販売に対する返品の発行まで540日です。

通常のルールは、販売時、遅くとも発行から24時間以内の提出です。それより古いレシートは失われるわけではありませんが、通常のチャネルにそのまま通すことはできません。納税者はまず遅延申請を行い、理由を述べ、ETAが毎年設定する割当の範囲内で対応します。申請には有効期間の制限もあり、デバイスはトークンに権限を反映させるために再認証が必要です。承認された申請の下で提出されたレシートは、元の発行日を保持します。ETAのレシート発行ドキュメントでは、この期間の上限を固定値ではなく設定パラメータとして扱っており、エジプトの税務ガイダンスは現在30日としています。

返品は最も長い時計で動きます。返品レシートは元の販売レシートのUUIDを参照する必要があり、その販売から540日後まで発行できます。返品は元の金額を超えることはできず、複数の部分返品を合計しても元の金額を超えることはできません。ソースドキュメントのない一般的なクレジット計上に相当するものはありません。参照のない返品は、必要なドキュメントの代替にはなりません。

バッチ制限も同じセクションに属します。オフラインキューが何をできるかを形作るからです。1回の提出には最大500件のレシートまたは1.5 MB、1件のレシートには最大300の明細行を含めることができ、平均は約10行です。1日接続を失った繁忙店では、時間制限に達する前に1回の提出制限を超えることがあり、同じ過大なバッチを再試行し続けるキューは、時計が進む間ずっと失敗し続けます。より小さな罠は、バッチが1つの単位として検証されることです。ETAのPOS FAQによれば、1件の無効なレシートがバッチ全体を無効にするため、1行の入力ミスが一緒に送信されたすべてのドキュメントを止める可能性があります。

微妙な時計はカレンダーです。発行タイムスタンプはUTCで保存され、エジプトはUTC+2、法律第24号（2023年）の下では4月下旬から10月下旬の間はUTC+3で運用されるため、5月1日の現地時間01:30に打たれたレシートは、4月30日の22:30 UTCとして記録されます。そのレシートはZレポートでは5月に属し、タイムスタンプから構築されたあらゆるグループ分けでは4月に属します。カイロの2026年の変更日は4月24日と10月30日で、年に2回オフセットが1時間ずれます。深夜を過ぎて営業する店では、月末の最後の数件のレシートが丸1日分の売上を前の期間に移すことがあります。

24時間の時計は経過時間を測ります。レシートがどの月に属するかは決めません。

月次チェックは3つの母集団を照合し、その順序が重要です

月末の照合では、3つの合計値ではなく3つの取引母集団を比較します。各レコードは異なる目的のために異なるプロセスで生成されており、それぞれが内部的に正しくても、他の2つと一致しないことがあるためです。

この比較には4つの役割が関わります。レジまたはPOSオペレーターはレシートを発行し、顧客用の控えを印刷し、カウンターで返品を処理します。会計士はその日の売上と返品を記帳し、Zレポートを元帳に突合し、月次のVAT申告を行います。これはほとんどの納税者にとって月次であり、法律第6号（2025年）の対象となる企業では四半期ごとです。ERP管理者は支店とデバイスのマッピング、品目コード、オフラインキューを含む提出連携を担当します。ETAポータルユーザーは支店とデバイスを登録し、クライアント認証情報を保持し、遅延申請を行います。単一支店の事業では、これらの役割のうち2つが同じ人物であることが多く、だからこそこのファイルは作成者以外の人にも読めるものでなければなりません。

比較の順序は判断であり、有用な順序は規模ではなく結果によるものです。まずETAの母集団から始めます。ドキュメントの欠落は法的なリスクであり、作業中にも回復の窓は閉じつつあるためです。次にPOSとERPを支店・デバイス単位で比較します。ここに会計上の誤りが潜むためです。最後に個々のレシートまで掘り下げます。1か月分の明細レベルの突合はコストが高く、最初の2ステップで判明した例外のために取っておくべきだからです。

値より先に件数を比較し、データが対応する最も細かいレベルで比較します。一致する全社合計は、ある支店が不足し別の支店が同額超過している状況を隠すことがあり、朝に不足し夕方に超過した支店は、元の取引が一度も一致していなくても完璧に締まることがあります。ドキュメントを数え、次に値を突合し、次に同一性を確認するという手順は、紙の上では遅く、実務では速いのです。各ステップが原因の分類を1つずつ排除するためです。

一致する全社合計は、ある支店が不足し別の支店が超過している状況を隠すことがあります。

複数店舗を展開するグループは、各店舗がどのPOSを運用していても、同じ抽出ルールで比較を構築すべきです。複数のレジシステムを1つの比較可能な売上サマリーに変換するワークフローは、3つのPOSシステムを使う5店舗を1つの比較可能な売上サマリーにで解説しており、同じ列設計がチェックのETA側にも引き継がれます。

記録が一致しなくなる5つの原因

三者間の差異はほぼすべて、5つの識別またはタイミングの問題のいずれかに起因し、それぞれ異なる対処が必要です。だからこそ、それらをすべて「記帳エラー」として扱うと1か月を無駄にします。

1. 印刷されたUUIDがETAの保持するUUIDと異なる

レシートが検証に失敗し、納税者が内容を修正すると、UUIDは変更後の内容から再計算されるため、修正後のレシートには新しいUUIDが付与されます。顧客が印刷した控えには依然として古いUUIDが記載されています。印刷されたUUIDで照合する財務チームは、ETAに記録のないドキュメントを見つけ、そのレシートは提出されなかったと判断して重複を再提出してしまいます。これを解決する証拠は、承認されたバージョンのreference old UUIDです。これは拒否されたドキュメントを指し示しており、承認された側は拒否された側のprevious UUIDを保持するため、デバイスチェーンが維持されます。

2. 結合に使うキーが一意でない

レシート番号は提出内の支店ごとに一意であり、会社全体で一意ではありません。そのため、12支店のグループでは、ある1日に1042番の有効なレシートが12枚存在し得ます。レシート番号だけで結合すると、レシートが誤った支店と組み合わされ、純粋に結合の産物である差異が生じます。同じ問題は、中央のERPが複数の店舗を単一の登録で発行する場合にも一段下のレベルで現れます。レシート上のデバイスシリアル番号は、売上と金額は正しいにもかかわらず、支店自身の記録が認識しないPOSを指しているのです。

3. 返品はマイナス売上として計上される

ETAは返品を独立したドキュメントタイプとして扱い、元の売上をUUIDで参照するため、照合ではこれを1件のドキュメントとして数える必要があります。返金を売上仕訳内のマイナス行として計上する会計システムでは、金額は正しく相殺されますがドキュメント数が合いません。するとその月は売上が一致しているのにドキュメント数が返品件数分不足し、提出漏れと誤診しやすくなります。何かを調整する前に、返品レシートを取得し参照UUIDで突合してください。

4. オフラインキューが24時間のラインを超えた

エジプトのガイダンスでは、レシートをオフラインで発行し、ローカルに保持して接続が回復したときに送信することが認められており、24時間のウィンドウがその保持期間の上限です。キューが1日止まると、POSとERPはETAが受信していない売上を保持したままになるため、POSとERPの比較は完全に一致し、ETAとの比較だけが不足します。対処法は会計上の修正ではありません。遅延申請、再認証、そしてウィンドウが閉じた後ではなく閉じる前に警告するキューモニターです。

5. 月の境界がずれた

照合でETAドキュメントをUTCの発行日でグループ化し、POSを営業日でグループ化すると、現地の深夜0時以降に計上された分だけ、両者の母集団は毎月末に食い違います。この差異は小さく、繰り返し発生し、決して解消しません。これはドキュメントの欠落ではなくグループ化の誤りの特徴です。比較する前にどちらか一方をもう一方に合わせて変換し、そのファイルがどちらの日付基準を使っているかを作業調書に明記してください。同じ変換は、オフセットが1時間ずれる4月と10月の夏時間の切り替え時にも重要です。

チェックを再現可能にする列

再現可能なチェックは、ドキュメントごとに1行、固定された列セットから始まります。最初の差異が現れてからではなく、最初のファイルを開く前に結合キーを選ぶ必要があるからです。

このテーブルに供給されるドキュメントは華やかなものではありません。POSから印刷された支店日締めレポート、PDFやスクリーンショットとして保存された検証ステータス画面、支店やスタッフが提出するレシート画像、会計システムからの仕訳エクスポートです。2025年1月以降、仕入れ側は拡大しました。経費が控除可能となるには電子インボイスまたはレシートの裏付けが必要であり、以前なら捨てられていたレシート画像を従業員が提出するようになったからです。

キーは同等ではなく、試す順序は固定されています。UUIDは当局がシステム全体で一意として扱うため、最も強力です。支店コード＋デバイスシリアル＋レシート番号は信頼できるフォールバックであり、UUIDが読み取れないか変更されている場合に使うキーです。発行時刻＋金額は最も弱く、別のキーで確立された一致を確認するだけにとどめるべきです。小売の1日は同額のレシートで溢れているからです。

テーブルができたら、他のドキュメントを必要とせず、1枚のレシート内で3つの算術チェックを実行します。明細合計は、レシート単位の割引を差し引いた印刷合計と一致するはずです。14%の標準税率が適用された明細では、税込合計に含まれる税額は、合計に14を掛けて114で割った値になります。この数字が合わない場合、その明細は非課税か、別の税率が適用されているか、入力ミスです。また、支払方法の内訳の合計も同じ合計と一致するはずです。これらにより、読み取りミスの桁が照合差異になる前に発見でき、1か月後に見つけるよりも低コストで済みます。

抽出が適する範囲と、その限界

抽出ステップは、このワークフローの中でドキュメントツールが担える唯一の部分であり、どの部分を担うのかを正確に把握することが、残りのチェックの信頼性を高めます。

ここでの作業は、固定レイアウトのない多数のドキュメントからのフィールド取得です。支店は稼働中のPOSから日締めレポートを印刷し、税務マネージャーは検証画面をPDFとして保存し、スタッフは3種類の異なるスマートフォンでレシートを撮影します。ImageToTable.aiはカスタム列抽出を使用します。「Receipt UUID」「Branch Code」「Device Serial」「Issue Date (UTC)」「Total」「Tax Amount」など、必要な列名を入力すると、AIがテンプレート上の固定位置ではなく、意味に基づいて各ドキュメント上の各値を特定します。入力した列名は、出力テーブルのヘッダーになります。

月末にこれを実用的にするのはバッチ処理です。1か月分の支店レポート、ステータスエクスポート、レシート画像を一度にアップロードすると、出力は1ドキュメントにつき1行の単一のスプレッドシートになります。日付と金額は出力時に正規化されるため、30/04/2026と印刷された日付と2026-04-30と印刷された日付は同じ形式になり、並べ替えや合計が可能です。

計算列は、1枚のレシート内に属する算術を処理します。「VAT at 14% (Total × 14 ÷ 114)」という名前の列は、各行の総額から導かれる税額を返し、明細金額の合計を印刷合計から差し引く列は、正常なレシートではゼロを、読み取りミスのあるものでは数値を返します。計算列ができないのは、2つの異なるドキュメント間でフィールドを比較することであるため、POSからERPへの結合と差異計算は、エクスポート後のスプレッドシート作業として残ります。

Bboxロケーティングを備えたレビューモードは、判断を左右するフィールドのための管理機能です。セルをクリックすると、元のページ上でその値の由来となった行がハイライトされるため、UUID、金額、発行日を探し回ることなく画像と照合できます。これは特にUUIDにとって重要で、UUIDは64桁の16進数文字列であり、テーブル内で最も融通の利かないフィールドです。64文字のハッシュをサーマルプリントから読み取るのは信頼できないため、支店、デバイス、レシート番号、金額の3つ組を主キーとして扱い、UUIDはクロスチェックとして使用してください。印刷されたレシートにETAのQRコードが含まれている場合、その中の共有リンクはレシート詳細ページに解決され、印刷された文字列よりも識別子の優れた情報源となります。

限界は明確に述べておく価値があります。過大に評価されたツールに基づいて構築されたコンプライアンスファイルは、ファイルがないよりも悪いからです。このツールは、レシートをETAに発行、署名、検証、提出することはなく、事業が対象範囲内かどうかを判断することもありません。レシートが法的に有効かどうかを教えることもなく、その記録を含むドキュメントを誰かが提供しない限り、当局の記録を見ることはできません。POSの母集団とERPの母集団を単独で結合することもありません。このツールが取り除くのは、サイレントエラーを生み出す再入力とページめくりであり、判断は残します。どの差異が修正で、どれが未提出で、どれがマッピングの不具合なのかという判断です。

印刷された表では精度が高く、認識率は最大99%、1ページあたり5～10秒で、手入力の約3分と比べられます。ただしレシート画像はすべてが印刷された表とは限りません。感熱紙は色あせ、折り目が合計に重なり、スマホ写真は斜めに撮影されます。ファイル全体を信頼する前にバッチをサンプリングし、すべてのフィールドを均等にではなく、結果を左右するフィールドを確認してください。フィールドのロジック自体は他の管轄区域でも馴染みのあるものです。すでに別の税務当局向けにVATレシートを取得している場合、UK VAT receipt field guideでは異なるルールセットで同じ列優先のアプローチを示しており、より広範な方法はcomplete guide to receipt data extractionにあります。

FAQ

2026年、すべてのエジプト企業は電子レシートを発行する必要がありますか？

いいえ。義務はETAの電子レシート決定に記載されたリストに従うものであり、VAT登録事業者すべてに適用される一般規則ではありません。ETAの義務照会で登録番号を検索し、日付入りの結果を保管してください。セグメントの期日がすでに過ぎているのにリストに記載されていない事業者は、システム外だと決めつけるべきではありません。任意登録が可能であり、後の決定で追加される可能性があるからです。

QRコードのない印刷された電子レシートは有効ですか？

納税者はQRコードを生成し、印刷されたレシートに配置する必要があり、コードはUUIDとUTC発行時刻を使ってレシート詳細ページを指します。それがなければ、たとえ基になるドキュメントが正しく提出されていても、印刷物は不完全な顧客用コピーです。照合では、印刷されたフィールドと当局が受理した記録が重要です。QRコードは顧客がその記録にたどり着く手段であり、提出が成功した証拠ではありません。

レジでインターネットが落ちたらどうなりますか？

レシートは発行でき、ローカルに保持され、接続が戻ったときに提出できますが、24時間の期限は進み続けます。キューがそれを逃すと、レシートは受理される前に遅延申請が必要になり、デバイスはトークンに権限が含まれるよう再認証する必要があります。キューのサイズではなくキューの経過時間を監視し、最も古い未送信レシートでアラートを出してください。

月次照合が合うように返品はどう記録すべきですか？

元の売上のUUIDを参照する独立した返品レシートとして記録し、売上仕訳の中にマイナスの行として入れてはいけません。返品は元の金額を超えることはできず、複数の部分返品を合計しても元の金額を超えることはできません。返品はドキュメント数に含めたままにし、金額の段階でのみ相殺してください。そうすることで、ドキュメント数と売上高がそれぞれ別の問いに答えることになります。

記録はどのくらいの期間保存する必要がありますか？

エジプトの税務ルールでは、帳簿、記録、裏付け書類を5年間保存することが一般的に求められており、電子記録も主要な記録として扱われます。顧客用の控えだけでなく、レシートのペイロード、当局の確認応答、検証エラー、修正版、照合ワークペーパーも保存してください。適用される期間は事業の内容によって変わり得るため、エジプトの税務アドバイザーに確認してください。

このツールはレシートをETAに代行提出できますか？

いいえ。提出、署名、検証は、デバイス認証情報とシーケンスを保持するPOSまたはERPの連携の中で行われます。このツールは、すでにお持ちのドキュメント（印刷されたレシート、支店レポート、保存されたステータス画面など）からデータを取り込み、3つの集計を比較できるよう1つのテーブルにまとめます。連携の代わりにはならず、ドキュメントが準拠しているかどうかを判断するものでもありません。

有用な変化は小さなものです。3つの集計が、明示されたキーと明示された日付基準を持つ1つのテーブルに収まれば、差異は月末の言い争いではなく、原因が紐づいた1つの行になります。まず1支店・1か月から始めてください。日締めレポート、元帳のエクスポート、ステータス画面を取得し、12列を一度入力して、誰かがポータルを開く前にどれだけの差異が解消されるか確認してください。1か月分のレシートを列ワークフローで処理し、何行が単一のドキュメントに解消されるか数えてみてください。