What the Egyptian Tax Authority actually asks a hotel to issue
The Egyptian Tax Authority (ETA) runs two related but separate systems that hotels get pulled into: the e-invoice system for business-to-business (B2B) sales, and the e-receipt system for business-to-consumer (B2C) sales. A hotel folio can end up on either side depending on who is paying, so the first thing front office and accounts need to agree on is a simple rule: is the buyer a registered company, or is the buyer an individual guest paying for themselves?
That single question decides the document type, the fields you must collect, and who signs the document. Get it wrong at check-in and you are re-issuing documents at check-out, which is where most of the rework in this process actually comes from — not from the technology itself.
| Document | Buyer | Typical trigger | Key extra field |
|---|---|---|---|
| E-invoice | Registered company or another taxable entity | Corporate account, travel agency, MICE group billed to a company | Buyer's tax registration number |
| E-receipt | Individual guest (walk-in, OTA-booked leisure guest, cash payer) | Personal stay, paid by the guest or their personal card | Guest identification (as required for the receipt), no company tax number |
What data the front desk needs to collect, and when
E-invoicing turns a data-collection problem that used to be an accounts problem into a front-desk problem, because most of the missing fields belong to check-in, not check-out. Waiting until departure to ask a corporate guest for their company's tax number is the single most common cause of delayed billing.
- At reservation or check-in, ask directly: is this stay billed to the guest personally, or to a company/agency?
- If billed to a company: capture the company's legal name exactly as registered, and its tax registration number, before the guest checks in if possible.
- If billed to an individual: capture the guest's name and identification as your receipt process requires — no tax registration number is needed for a B2C e-receipt.
- If billing changes mid-stay (a guest's employer takes over the bill, or a group splits into individual folios), record that change on the folio immediately, not as a note for accounts to interpret later.
- Confirm the buyer type again before check-out, because it is the last point where a correction is still cheap.
A folio with a missing or wrong tax registration number is not a small clerical gap — it is the difference between a valid e-invoice and one that has to be cancelled and reissued, with everything that follows from a credit note.
When to issue the e-invoice or e-receipt: at check-out, from the folio
The practical rule hotels should follow is to issue the e-invoice or e-receipt at check-out, generated directly from the closed folio, once all charges for the stay are posted and the folio balance is settled or otherwise resolved. Issuing earlier risks charges landing on the guest's account after the document has already gone out; issuing later delays the guest's copy and creates a backlog for accounts to chase.
This is also why the folio itself needs to be accurate before you generate anything: room charges, meal plan charges, restaurant postings, mini-bar, and any late adjustments should all be on the folio and reviewed before the document is produced, not patched in afterwards.
This is where Mukeem fits the workflow rather than adding a step to it: because the folio is the single ledger for the stay, the e-invoice or e-receipt is generated from the same closed folio the cashier already balanced, rather than from a separate export that someone has to reconcile by hand.
Deposits, advance payments and refunds: what documents they need
Deposits and advance payments are where hotels most often get the sequencing wrong, because the money moves before the stay — and sometimes before the room type or dates are even final.
- A deposit taken well before arrival is a payment on account. Depending on your accounting setup and the buyer type, it may need its own documentation at the time it is received, separate from the final stay document issued at check-out — confirm this with your accountant rather than assuming either way.
- When the stay is completed, the final e-invoice or e-receipt should reflect the full charges for the stay, with the deposit shown as a payment already applied — not as a separate, unexplained reduction in the total.
- A cancellation with the deposit forfeited, or a rate change agreed after a document has already been issued, is corrected with a credit note referencing the original document — never by editing or deleting the original.
- A partial refund (for example, a service the guest did not receive) follows the same rule: a credit note for the refunded amount, tied back to the original invoice or receipt.
Handling credit notes without breaking the audit trail
A credit note is not a workaround — it is the mechanism the system expects for every downward correction after issuance. Treat it as a normal, expected part of the process rather than an error report, and your accounts team will spend far less time explaining discrepancies later.
| Situation | Correct action |
|---|---|
| Wrong tax registration number entered for a company | Credit note for the full amount, then a new correct e-invoice |
| Guest disputes one posted charge after check-out | Credit note for that line only, referencing the original document |
| Rate renegotiated after the invoice was already issued | Credit note for the difference, or full credit note plus reissue, depending on your accountant's guidance |
| Duplicate document issued by mistake | Full credit note against the duplicate |
Whatever the case, the original document stays in the record exactly as issued. That is what keeps the trail auditable, and it is exactly the discipline that a folio-driven e-invoicing flow like Mukeem's enforces by design — corrections are new documents, not silent edits.
Common mistakes that create rework
- Asking for the company tax registration number at check-out instead of check-in, when the guest has already left the desk and moved on.
- Treating a travel-agency group booking as a B2C receipt because individual guests occupied the rooms, when the contracted buyer is the agency.
- Editing a folio or a document after issuance instead of raising a credit note.
- Issuing the stay document before the folio is fully posted, then discovering a late restaurant charge or mini-bar posting.
- Not documenting a mid-stay change of buyer (personal to corporate, or vice versa) on the folio itself, leaving accounts to guess at month-end.
- Assuming a deposit and a final invoice are the same document — they usually are not, and conflating them is a frequent source of ETA-facing errors.
None of these mistakes are about the technology failing; they are about the front desk and accounts not agreeing on buyer type, timing and correction rules before the guest arrives. Fix the process and the documents mostly take care of themselves.
Getting the front desk and accounts on the same page
The teams that handle this well share three habits: they decide buyer type at booking or check-in, not check-out; they never touch an issued document except with a credit note; and they treat the folio, not a spreadsheet, as the single source of truth for what the e-invoice or e-receipt should say.
Mukeem supports that by keeping cashier postings, the folio and e-invoicing on one ledger, and by carrying every charge through to the general ledger through accounting so the document a guest receives always matches what your books show. For the wider stack — front desk, night audit and multi-property reporting — the same folio-first principle applies across the system.