Los requisitos de e-receipt de Egipto en 2026
dependen de tres registros
El despliegue del e-receipt en Egipto ya no tiene una próxima fecha que esperar. La última fecha de inicio en el calendario del Ministro de Finanzas fue el 31 de diciembre de 2025, y una revisión de la lista de obligaciones de la ETA realizada por una firma de contabilidad egipcia el 9 de octubre de 2026 no encontró ninguna fase posterior. Para cualquier empresa ya mencionada en una decisión, la pregunta de 2026 no es si las reglas aplican. Es si la caja registradora, el libro mayor y el propio registro de la autoridad fiscal pueden demostrar que describen el mismo mes de ventas.
Esa prueba es más difícil de lo que parece, porque tres sistemas registran la misma venta por tres razones distintas, y no coinciden por motivos que no tienen nada que ver con una mala contabilidad. Esta guía cubre la prueba de alcance, el conjunto de campos de Receipt v1.2, los plazos de envío y el flujo de devoluciones, y luego recorre la verificación mensual y los cinco problemas específicos que la rompen. Está escrita para el contador o el responsable de finanzas que debe firmar la conciliación, no para quien firmó el contrato del POS.

Puntos clave
- La caja registradora, el libro mayor y la ETA pueden ser correctos según sus propios criterios y aun así no coincidir sobre el mismo mes.
- Un total a nivel de empresa que coincide puede ocultar que una sucursal está corta y otra larga por el mismo importe.
- A fin de mes, su tarea es decidir qué diferencia es una corrección, cuál es un envío faltante y cuál es un defecto de mapeo.
En 2026, la prueba de alcance es su número de registro, no su facturación
Una empresa está obligada a emitir recibos electrónicos cuando su número de registro de contribuyente aparece en una decisión de obligación publicada por el titular de la Autoridad Tributaria Egipcia (ETA), y ninguna cifra de facturación responde a esa pregunta.
El sistema de recibos electrónicos es la mitad B2C de la infraestructura tributaria digital de Egipto. El sistema de facturas electrónicas, que se basa en la decisión ministerial n.º 188 de 2020, cubre las ventas entre empresas y a organismos gubernamentales. El sistema de recibos electrónicos cubre las ventas al consumidor final y se basa en los artículos 35 y 37 de la ley n.º 206 de 2020 sobre procedimientos tributarios unificados, implementada mediante la decisión ministerial n.º 230 de 2022, modificada por la decisión n.º 38 de 2024. Un minorista con clientes mayoristas gestiona ambos, y una misma transacción nunca pertenece a los dos.
La obligación llegó por fases, cada una una decisión separada con una lista adjunta de contribuyentes nombrados y una fecha de inicio. Los últimos pasos programados eran así:
| Fase | A quién cubría el calendario | Fecha de inicio y decisión |
|---|---|---|
| 7 | Salud, cuidado personal y telecomunicaciones | 1 de julio de 2025 (decisión n.º 123 de 2025) |
| 8 | Transporte por aplicaciones, mantenimiento y limpieza | 15 de julio de 2025 para el Gran Cairo y Alejandría, 15 de septiembre de 2025 en el resto (decisiones n.º 225 y 281 de 2025) |
| 9 | Supermercados y otras actividades | 15 de noviembre de 2025 para el Gran Cairo y Alejandría (decisión n.º 361 de 2025), 31 de diciembre de 2025 en el resto según el calendario del Ministro |
Las fechas y los números de decisión anteriores son los del calendario del Ministro y las decisiones de la ETA, tal como se resumen en esta tabla fase por fase de Nassef & Partners International, una firma de contabilidad egipcia. Dos detalles importan más que las fechas. La fecha de inicio que vincula a una empresa es la de la decisión que la nombra, que puede diferir de la fecha del calendario del Ministro. Y un segmento cuya fecha programada ya pasó no queda automáticamente fuera de alcance, porque el registro voluntario siempre ha estado abierto. La comprobación práctica es buscar el número de registro en la consulta de obligaciones de la ETA, guardar el resultado con la fecha de la consulta y repetirla tras una fusión, una reorganización de sucursales o una nueva decisión.
La cifra de EGP 150.000 que circula en los resúmenes de los requisitos de recibos electrónicos de Egipto no es un umbral de alcance. Es una regla de identificación del comprador dentro de Receipt v1.2: cuando el comprador es una persona natural y el total del recibo alcanza EGP 150.000 o más, el DNI y el nombre del comprador pasan a ser campos obligatorios. El umbral de registro del IVA, y el techo de EGP 20 millones para el régimen simplificado según la ley n.º 6 de 2025, responden a preguntas distintas. Ninguno sustituye a la lista de obligaciones.
Un número de registro del IVA introduce a una empresa en el sistema tributario. No la introduce en una decisión de recibos electrónicos.
La consecuencia de estar identificado es concreta. No emitir un recibo, o emitirlo sin los datos exigidos por el artículo 37, expone al negocio a una multa de EGP 20,000 a EGP 100,000 según el artículo 71. Además, desde enero de 2025 un costo solo es deducible si está respaldado por una factura o recibo electrónico, lo que traslada la misma regla al lado de las compras del libro contable. Y la condición de adhesión al régimen tributario simplificado ahora incluye la participación en los sistemas electrónicos de la ETA, por lo que la obligación del recibo electrónico acompaña al negocio dentro del régimen que debía simplificar su declaración.
Distintos países han construido la misma capacidad con una arquitectura diferente, y la elección de diseño cambia lo que finanzas debe conciliar. Francia canaliza las facturas B2B a través de plataformas certificadas según el artículo 91 de su Ley de Finanzas de 2024, lo que convierte a la plataforma en el punto de control. Egipto coloca la secuencia y el historial de correcciones en el dispositivo del contribuyente. Si usted trabaja en ambos, la guía de facturación electrónica en Francia 2026 cubre el otro modelo.
Un recibo contiene dos conjuntos de campos, y solo uno de ellos trata sobre la venta
Receipt v1.2 divide el documento en datos comerciales que describen lo que se vendió y datos de control que prueban que el documento provino de un dispositivo autorizado en la secuencia correcta, y los equipos de finanzas suelen capturar solo los primeros.
Las versiones 1.0 y 1.1 del recibo están retiradas, por lo que la 1.2 es la base para cualquier integración que se construya ahora. El esquema de Receipt v1.2 es público, lo que significa que no hay excusa para una lista de campos armada a partir del resumen de un proveedor. La capa comercial cubre al vendedor, la sucursal, las líneas de artículos y los totales. La capa de control cubre los identificadores que hacen que el recibo sea localizable y la cadena que hace difícil eliminar uno sin dejar un vacío.
| Grupo de datos | Qué exige Receipt v1.2 | Qué controla |
|---|---|---|
| Emisión | Fecha y hora de emisión en UTC, número de recibo, tipo de venta o devolución, versión del documento | Cuándo se emitió el documento y a qué mes pertenece |
| Vendedor y origen | Número de registro, nombre comercial, código de sucursal, dirección de la sucursal, número de serie del dispositivo, código de actividad | Qué entidad legal, sucursal y dispositivo físico lo emitió |
| Comprador | Tipo de comprador (empresa, persona natural, extranjero), ID y nombre, móvil o referencia de pago cuando corresponda | Si el cliente debía identificarse en este recibo |
| Artículos | Código interno, descripción, código GS1 o EGS, unidad, cantidad, precio unitario, venta bruta, descuentos, venta neta, impuesto y total de la línea | Si el impuesto de cada línea puede recalcularse |
| Totales | Ventas totales, descuentos comerciales y por artículo, importe neto, totales de impuestos, importe total, método de pago | Si el detalle de las líneas suma la cifra que pagó el cliente |
| Controles del sistema | UUID, previous UUID, reference old UUID, moneda y tipo de cambio | Identidad, secuencia e historial de un documento corregido |
Los controles del sistema merecen una lectura más pausada, porque se comportan de forma distinta a lo que está acostumbrado cualquier contable. El UUID no lo asigna la autoridad. Es un hash SHA-256 de 64 caracteres calculado a partir del contenido normalizado del propio recibo. Cualquier cambio en el contenido produce un UUID distinto. El previous UUID apunta al último documento emitido por el mismo dispositivo POS, de modo que cada caja mantiene su propia cadena y solo el primer documento de ese dispositivo puede llevar un valor vacío. Cuando un recibo falla la validación y hay que corregirlo, la versión corregida conserva el previous UUID original y coloca el UUID rechazado en reference old UUID, lo que preserva un vínculo consultable entre ambas versiones. El esquema CFDI de México se enfrenta a un problema de identidad comparable y lo resuelve con un timbre fiscal, como expone la guía de extracción de facturas CFDI. La diferencia es que el identificador egipcio se deriva de contenido que el contribuyente puede editar, y por eso precisamente las correcciones lo modifican.
Otros dos campos tienen un alcance más limitado de lo que parece. El número de recibo es único por sucursal dentro del mismo envío, no en toda la empresa. Un grupo con doce sucursales puede tener legítimamente un recibo numerado 1042 en cada una de ellas el mismo día. Y la marca de tiempo de emisión se registra en UTC, mientras que la impresora, el cajero y el informe Z, el informe de cierre de fin de día que se imprime desde la caja, trabajan todos en hora local de El Cairo. Ambos puntos parecen triviales hasta que la conciliación de fin de mes usa el equivocado como clave.
La regla del comprador es el campo que más se malinterpreta. El tipo de comprador B exige el número y el nombre del registro mercantil. El tipo de comprador P exige el documento nacional de identidad y el nombre solo cuando el total alcanza los EGP 150,000, y ese umbral se aplica a los recibos de la versión 1.2 y posteriores; las versiones anteriores usaban EGP 50,000. Un recibo de cafetería por EGP 240 necesita un total, un método de pago y una sucursal, no el documento nacional de identidad del cliente.
El UUID es una huella del contenido del recibo, no un número de factura. Cambie un solo carácter y la huella cambia con él.
Cuatro condiciones deben cumplirse antes de que un dispositivo pueda enviar
Un dispositivo que no ha sido registrado y activado puede registrar una venta correcta todo el día y aun así no producir nada que ETA acepte, por lo que la lista de verificación de incorporación forma parte de la historia de conciliación y no de un proyecto de TI aparte.
La primera condición es una sucursal registrada que siga activa en la fecha de emisión; la autoridad valida las fechas de actividad de la sucursal y detendrá la emisión desde una sucursal cesada. La segunda es un punto de venta registrado contra esa sucursal, con un número de serie único por dispositivo y vinculado al número de registro del vendedor antes de emitir cualquier recibo. La tercera es la etiqueta B2C en el perfil del contribuyente, porque un contribuyente sin ella no puede enviar recibos por ningún canal. La cuarta es la codificación de artículos bajo GS1 o el sistema Egyptian Goods and Services (EGS), con los códigos que el contribuyente está realmente autorizado a usar. Un punto de venta que envía descripciones internas en lugar de códigos autorizados fallará la validación después de haber cobrado el dinero.
El caso del ERP tiene su propia trampa. Las preguntas frecuentes sobre puntos de venta de ETA permiten registrar un sistema contable de una sola sucursal como un único POS de software. Cuando un ERP central emite para varios puntos de venta, cada punto de venta debe registrarse como un POS separado para que el recibo identifique la fuente correcta. Los equipos que registran el ERP una sola vez y lo dejan emitir para todas las sucursales terminan con recibos comercialmente correctos pero estructuralmente erróneos, y la discrepancia solo se hace visible cuando una conciliación a nivel de sucursal no encuentra sus propias ventas.
El token de envío añade una condición que sigue aplicándose después de la puesta en marcha. Identifica al contribuyente propietario del POS, y los datos del emisor y del dispositivo en el recibo deben coincidir con esa autorización. Después de que ETA cambie un permiso, y en particular después de que se apruebe una solicitud de envío tardío, el dispositivo debe autenticarse de nuevo antes de que el permiso actualizado aparezca en su token. Una cola de recibos que sigue fallando sin motivo visible suele ser un token obsoleto y no una carga útil defectuosa.
Tres relojes deciden si un recibo existe

Tres plazos distintos rigen un recibo electrónico egipcio, y vencen en escalas completamente diferentes: 24 horas para enviarlo, 30 días para recuperar un recibo tardío y 540 días para emitir una devolución contra la venta original.
La regla normal es enviarlo en el momento de la venta y a más tardar 24 horas después de la emisión. Un recibo más antiguo no se pierde, pero no puede simplemente enviarse por el canal normal. El contribuyente primero presenta una solicitud de envío tardío, indica un motivo y opera dentro de una cuota que la ETA fija por año; la solicitud también tiene un periodo activo limitado, y el dispositivo debe volver a autenticarse para que su token lleve el permiso. Los recibos enviados bajo una solicitud aprobada conservan su fecha de emisión original. La documentación de la ETA sobre emisión de recibos trata el límite exterior de esa ventana como un parámetro de configuración y no como un número fijo, y la guía fiscal egipcia actualmente lo describe como 30 días.
Las devoluciones funcionan con el reloj más largo. Un recibo de devolución debe referenciar el UUID del recibo de venta original, y puede emitirse hasta 540 días después de esa venta. Una devolución no puede superar el importe original, y varias devoluciones parciales no pueden sumar más que el original. No existe un equivalente a un abono genérico sin documento de origen: una devolución sin la referencia no sustituye al documento exigido.
Los límites de lote pertenecen a esta misma sección porque determinan lo que puede hacer una cola sin conexión. Un solo envío puede contener hasta 500 recibos o 1,5 MB, y un solo recibo puede contener hasta 300 líneas, con un promedio de unas 10 líneas. Una tienda con mucho movimiento que pierde la conexión durante un día puede superar el límite por envío antes de superar el límite de tiempo, y una cola que reintenta el mismo lote sobredimensionado seguirá fallando mientras el reloj avanza. La trampa más pequeña es que un lote se valida como una unidad: las preguntas frecuentes sobre POS de la ETA indican que un recibo no válido invalida todo el lote, así que una sola línea mal tecleada puede bloquear todos los documentos enviados con ella.
El reloj sutil es el calendario. Como la marca de tiempo de emisión se almacena en UTC y Egipto funciona en UTC+2, o UTC+3 entre finales de abril y finales de octubre según la ley n.º 24 de 2023, un recibo registrado a las 01:30 hora local del 1 de mayo queda grabado a las 22:30 UTC del 30 de abril. Ese recibo pertenece a mayo en el informe Z y a abril en cualquier agrupación construida a partir de la marca de tiempo. Las fechas de cambio de 2026 para El Cairo son el 24 de abril y el 30 de octubre, lo que desplaza el desfase una hora dos veces al año. Para una tienda que opera pasada la medianoche, los últimos recibos de un mes pueden trasladar un día entero de ingresos al periodo anterior.
El reloj de 24 horas mide el tiempo transcurrido. No decide a qué mes pertenece el recibo.
La conciliación mensual reconcilia tres poblaciones, y el orden importa
La conciliación de fin de mes compara tres poblaciones de transacciones, no tres totales, porque cada registro fue producido por un proceso distinto con un propósito distinto y cada uno puede ser internamente correcto mientras discrepa de los otros dos.
| Registro | Responsable | Responde | No puede decirle |
|---|---|---|---|
| Ventas y devoluciones del POS | Gerente de sucursal, supervisor de caja, administrador del ERP | Qué registró la caja, por dispositivo, por día, por método de pago | Si el documento fue aceptado, o si la codificación del artículo era válida |
| Registros contables del ERP | Contador, tenedor de libros | Qué se reconoció como ingreso, impuesto y descuento en el libro mayor | Si la caja y la autoridad vieron la misma transacción |
| Documentos aceptados y rechazados por la ETA | Gerente de impuestos, usuario autorizado del portal | Qué recibos existen como documentos fiscales, en qué secuencia y con qué estado | Si ocurrió una venta que nunca se envió |
Cuatro roles intervienen en esta comparación. El cajero o el operador del POS emite el recibo, imprime la copia del cliente y gestiona la devolución en el mostrador. El contador registra las ventas y devoluciones del día, vincula el informe Z con el libro mayor y presenta la declaración mensual del IVA, que para la mayoría de los contribuyentes es mensual y para las empresas dentro de la ley n.º 6 de 2025 es trimestral. El administrador del ERP es responsable del mapeo de sucursales y dispositivos, de los códigos de artículos y de la integración de envío, incluida la cola sin conexión. El usuario del portal de la ETA registra sucursales y dispositivos, posee las credenciales del cliente y presenta solicitudes de envío tardío. En un negocio de una sola sucursal, dos de esos roles suelen ser la misma persona, y por eso el archivo debe ser legible para alguien que no lo creó.
El orden de comparación es un criterio, y el orden útil es por consecuencia y no por tamaño. Comience con la población de la ETA, porque un documento faltante es una exposición legal y la ventana de recuperación se cierra mientras usted trabaja. Luego compare el POS con el ERP a nivel de sucursal y dispositivo, porque ahí es donde se ubicará un error contable. Después profundice en recibos individuales, porque la coincidencia a nivel de línea durante un mes es costosa y debe reservarse para las excepciones que produjeron los dos primeros pasos.
Compare recuentos antes que valores, y compárelos al nivel más granular que los datos permitan. Un total de empresa que coincide puede ocultar una sucursal con faltante y otra con sobrante por el mismo importe, y una sucursal con faltante por la mañana y sobrante por la tarde puede cerrar perfectamente mientras las transacciones subyacentes nunca coincidieron. Contar documentos, luego cotejar el valor y después verificar la identidad es más lento sobre el papel y más rápido en la práctica, porque cada paso descarta una clase de causa.
Un total a nivel de empresa que coincide puede ocultar una sucursal con faltante y otra con sobrante.
Los grupos con varias tiendas deben construir la comparación con la misma disciplina de extracción, independientemente del POS que use cada tienda. El flujo de trabajo para convertir varios sistemas de caja en un resumen de ventas comparable se cubre en cinco tiendas en tres sistemas POS, un resumen de ventas comparable, y el mismo diseño de columnas se traslada al lado del ETA del cheque.
Cinco formas en que los registros dejan de coincidir

Casi todas las diferencias triples se remontan a uno de cinco problemas de identidad o de sincronización, y cada uno requiere una solución distinta, por lo que tratarlos todos como "errores de contabilidad" hace perder el mes.
1. El UUID impreso no es el UUID que tiene ETA
Cuando un recibo falla la validación y el contribuyente corrige el contenido, el recibo corregido obtiene un nuevo UUID porque el UUID se recalcula a partir del contenido modificado. La copia impresa del cliente aún lleva el antiguo. Un equipo de finanzas que compara por el UUID impreso encontrará un documento del que ETA no tiene registro, concluirá que el recibo nunca se envió y reenviará un duplicado. La evidencia que resuelve esto es el UUID anterior de referencia en la versión aceptada: apunta al documento rechazado, y el aceptado conserva el UUID anterior del rechazado para que la cadena del dispositivo permanezca intacta.
2. La clave por la que une no es única
Los números de recibo son únicos por sucursal dentro de un envío, no en toda la empresa, por lo que un grupo de doce sucursales puede tener doce recibos válidos numerados 1042 en un día. Unir solo por el número de recibo emparejará un recibo con la sucursal equivocada y producirá una diferencia que es puramente un artefacto de la unión. El mismo fallo aparece un nivel más abajo cuando un ERP central emite para varios puntos de venta bajo un único registro: el número de serie del dispositivo en el recibo apunta a un POS que el propio registro de la sucursal no reconoce, aunque la venta y el importe sean correctos.
3. Una devolución se registra como una venta negativa
ETA trata una devolución como su propio tipo de documento, que referencia la venta original por UUID, y la conciliación debe contarla como un documento. Un sistema contable que registra un reembolso como una línea negativa dentro del libro de ventas cuadra el valor correctamente y deja mal el recuento de documentos. El mes muestra entonces ingresos coincidentes y un recuento de documentos inferior en el número de devoluciones, algo fácil de diagnosticar erróneamente como envíos faltantes. Extraiga los recibos de devolución y concilielos por el UUID de referencia antes de ajustar nada.
4. La cola sin conexión cruzó la línea de las 24 horas
La normativa egipcia permite emitir un recibo sin conexión, guardarlo localmente y enviarlo cuando vuelva la conectividad, y la ventana de 24 horas es el límite de cuánto puede durar eso. Una cola que se queda atascada un día deja al POS y al ERP con ventas que ETA nunca recibió, así que la comparación POS-ERP coincide perfectamente y la comparación con ETA queda corta. La solución no es una corrección contable. Es una solicitud de envío tardío, una reautenticación y un monitor de cola que avise mucho antes de que se cierre la ventana, no después.
5. El límite del mes se desplazó
Si la conciliación agrupa los documentos de ETA por su fecha de emisión en UTC y agrupa el POS por fecha comercial, las dos poblaciones discreparán en cada cierre de mes por todo lo que se registró después de la medianoche local. La diferencia es pequeña, repetible y nunca se resuelve, lo que es la firma de un error de agrupación y no de un documento faltante. Convierta un lado al otro antes de comparar, e indique en el papel de trabajo qué base de fecha usa el archivo. La misma conversión importa en los cambios de horario de verano de abril y octubre, cuando el desfase se desplaza una hora.
| Lo que ve | Causa más probable | Qué extraer primero |
|---|---|---|
| POS y ERP coinciden, ambos superan a ETA en un bloque de ventas | La cola sin conexión nunca se envió, o el envío se rechazó en bloque | El registro de envíos del dispositivo para la fecha, y luego el estado en ETA por dispositivo |
| El valor coincide, el recuento de documentos queda corto | Devoluciones registradas como ventas negativas en lugar de documentos separados | Los recibos de devolución y sus UUID de referencia |
| Una sucursal queda sistemáticamente corta en un número redondo | Mapeo de dispositivo o sucursal, o un POS registrado bajo otro punto de venta | El código de sucursal y el número de serie del dispositivo en ambos lados |
| Un solo recibo nunca coincide y parece duplicado | Recibo corregido reemitido con un nuevo UUID | El UUID anterior de referencia y el UUID de la copia impresa |
| El último día de cada mes discrepa en unos pocos recibos | Fecha de emisión en UTC frente a fecha comercial local | Las marcas de tiempo de emisión en UTC y la fecha comercial del informe Z |
| Falta un día entero pero la caja cerró con normalidad | Dispositivo retirado o bloqueado, o un token obsoleto tras un cambio de permisos | El estado del dispositivo, las declaraciones del token y los mensajes de validación |
Las columnas que hacen repetible la verificación
Una verificación repetible comienza con una fila por documento y un conjunto fijo de columnas, porque la clave de unión debe elegirse antes de abrir el primer archivo y no después de que aparezca la primera diferencia.
Los documentos que alimentan esta tabla no son llamativos. Son el informe de cierre diario de sucursal impreso desde el POS, la pantalla de estado de validación guardada como PDF o captura de pantalla, las imágenes de recibo que entregan las sucursales y el personal, y la exportación del libro diario del sistema contable. Desde enero de 2025 el lado de compras ha crecido, porque un costo necesita respaldo de factura electrónica o recibo para ser deducible, lo que significa que los empleados ahora envían imágenes de recibos que antes se desechaban.
| Columna a capturar | Proviene de | Por qué la verificación la necesita |
|---|---|---|
| UUID del recibo | Recibo impreso o registro de ETA | La identidad más sólida, pero solo cuando se lee correctamente |
| UUID anterior y UUID de referencia antiguo | Registro de ETA | Reconstruye la cadena del dispositivo y explica un recibo corregido |
| Número de recibo | Recibo impreso | Clave de negocio, válida solo junto con sucursal y dispositivo |
| Código de sucursal y nombre de sucursal | Encabezado del recibo y registro de ETA | Localiza una excepción en un solo punto de venta |
| Número de serie del dispositivo | Encabezado del recibo y registro de ETA | Separa un problema del dispositivo de un problema de la sucursal |
| Número de registro del vendedor | Encabezado del recibo | Confirma la entidad legal emisora en un grupo con varias entidades |
| Fecha y hora de emisión en UTC | Encabezado del recibo | Ubica el recibo en la línea de tiempo de la autoridad |
| Fecha comercial | Informe Z | Ubica la venta en el día comercial de la sucursal |
| Tipo de documento (venta o devolución) | Encabezado del recibo | Mantiene las devoluciones contables en lugar de compensarlas |
| Importe total e importe de impuesto | Totales del recibo | Coincidencia de valor, y una verificación de que impuesto y bruto concuerden |
| Método de pago | Totales del recibo | Separa efectivo y tarjeta para poder cuadrar la banca del día |
| Estado de envío | Registro de ETA | Distingue un documento aceptado de uno rechazado o faltante |
Las claves no son equivalentes, y el orden para probarlas es fijo. El UUID es la más sólida porque la autoridad lo trata como único en todo el sistema. Código de sucursal más número de serie del dispositivo más número de recibo es el respaldo confiable, y es la clave que debe usar cuando el UUID es ilegible o ha cambiado. Hora de emisión más importe es la más débil y solo debe confirmar una coincidencia que otra clave haya establecido, porque un día de ventas al por menor está lleno de recibos por el mismo importe.
Una vez que existe la tabla, tres comprobaciones aritméticas se ejecutan dentro de un solo recibo sin necesidad de ningún otro documento. Los totales de línea deben sumar el total impreso, menos cualquier descuento a nivel de recibo. Para una línea gravada al tipo estándar del 14%, el impuesto incluido en un total con impuesto es el total multiplicado por 14 y dividido entre 114; una cifra que no cuadra significa que la línea está exenta, gravada a otro tipo o mal tecleada. Y el desglose por método de pago debe sumar ese mismo total. Estas comprobaciones detectan un dígito mal leído antes de que se convierta en una diferencia de conciliación, lo cual es más barato que descubrirlo un mes después.
Dónde encaja la extracción y dónde se detiene
La extracción es la única parte de este flujo de trabajo que una herramienta de documentos puede asumir, y ser preciso sobre qué parte asume es lo que hace fiable el resto de la comprobación.
La labor aquí es la captura de campos en muchos documentos sin un diseño fijo. Una sucursal imprime su informe de cierre diario desde el POS que utilice, un responsable fiscal guarda la pantalla de validación como PDF y el personal fotografía recibos con tres teléfonos distintos. ImageToTable.ai utiliza Custom Column Extraction: usted escribe los nombres de columna que desea, como "Receipt UUID", "Branch Code", "Device Serial", "Issue Date (UTC)", "Total" y "Tax Amount", y la IA localiza cada valor en cada documento por lo que significa, no por una posición fija en una plantilla. Los nombres de columna que usted escribe se convierten en los encabezados de la tabla de salida.
El procesamiento por lotes es lo que hace esto práctico a fin de mes. Suba un mes de informes de sucursal, exportaciones de estado e imágenes de recibos de una sola vez, y la salida es una única hoja de cálculo con una fila por documento. Las fechas y los importes se normalizan en la salida, de modo que una fecha impresa como 30/04/2026 y otra impresa como 2026-04-30 quedan en el mismo formato y se pueden ordenar y sumar.
Las columnas calculadas gestionan la aritmética que corresponde dentro de un solo recibo. Una columna llamada "VAT at 14% (Total × 14 ÷ 114)" devuelve el impuesto implícito en el importe bruto de cada fila, y una columna que resta la suma de los importes de línea del total impreso devuelve cero para un recibo correcto y un número para uno mal leído. Lo que no hacen las columnas calculadas es comparar campos entre dos documentos distintos, por lo que la unión POS-ERP y el cálculo de diferencias siguen siendo trabajo de hoja de cálculo tras la exportación.
El Review Mode con localización por Bbox es el control para los campos que conllevan la decisión. Haga clic en una celda y la página original resalta la línea de la que proviene el valor, de modo que un UUID, un importe o una fecha de emisión se pueden verificar contra la imagen sin tener que buscarlos. Esto es más importante para el UUID, que tiene 64 caracteres hexadecimales y es el campo menos indulgente de la tabla. Leer un hash de 64 caracteres de una impresión térmica no es fiable, así que trate la terna sucursal, dispositivo y número de recibo junto con el importe como clave primaria y use el UUID como verificación cruzada. Cuando un recibo impreso lleva el código QR de ETA, el enlace para compartir que contiene resuelve a la página de detalle del recibo y es una mejor fuente para el identificador que la cadena impresa.
Conviene enunciar los límites con claridad, porque un expediente de cumplimiento basado en una herramienta sobrevalorada es peor que no tener expediente. La herramienta no emite, firma, valida ni envía recibos a ETA, y no decide si una empresa está dentro del ámbito de aplicación. No le dice si un recibo es legalmente válido, y no puede ver el registro de la autoridad a menos que alguien le proporcione un documento que contenga ese registro. No une por sí sola la población del POS con la del ERP. Lo que elimina es la reescritura y el ir pasando páginas que producen errores silenciosos, y deja el juicio: qué diferencia es una corrección, cuál es un envío faltante y cuál es un defecto de mapeo.
La precisión es alta en tablas impresas, con hasta un 99 % de reconocimiento y de 5 a 10 segundos por página frente a unos 3 minutos de entrada manual, pero las imágenes de recibos no son todas tablas impresas. El papel térmico se desvanece, los pliegues cruzan el total y las fotos de teléfono llegan en ángulo. Muestree el lote antes de confiar en todo el archivo y revise los campos que deciden el resultado en lugar de todos los campos por igual. La lógica de los campos es familiar de otras jurisdicciones; si ya captura recibos de IVA para otra autoridad tributaria, la guía de campos del recibo de IVA del Reino Unido muestra el mismo enfoque de columnas primero con un conjunto de reglas distinto, y el método más amplio está en la guía completa de extracción de datos de recibos.
Preguntas frecuentes
¿Toda empresa egipcia debe emitir recibos electrónicos en 2026?
No. La obligación sigue las listas nombradas en las decisiones de recibo electrónico de la ETA, no una regla general para todas las empresas registradas en el IVA. Busque el número de registro en la consulta de obligaciones de la ETA y conserve el resultado con fecha. Una empresa cuyo segmento ya pasó su fecha pero que no está nombrada no debe asumir que está fuera del sistema, porque el registro voluntario está disponible y una decisión posterior puede incluirla.
¿Es válido un recibo electrónico impreso sin el código QR?
El contribuyente debe generar un código QR y colocarlo en el recibo impreso, y el código apunta a la página de detalle del recibo usando el UUID y la hora de emisión en UTC. Una impresión sin él es una copia incompleta para el cliente aunque el documento subyacente se haya enviado correctamente. Para la conciliación, lo que importa son los campos impresos y el registro aceptado por la autoridad; el código QR es la vía del cliente a ese registro, no prueba de que el envío haya tenido éxito.
¿Qué pasa si se cae el internet en la caja?
El recibo aún puede emitirse, guardarse localmente y enviarse cuando vuelva la conectividad, pero la ventana de 24 horas sigue corriendo. Si la cola no la cumple, los recibos necesitan una solicitud de envío tardío antes de poder aceptarse, y el dispositivo debe volver a autenticarse para que su token lleve el permiso. Supervise la antigüedad de la cola en lugar de su tamaño, y active alertas para el recibo sin enviar más antiguo.
¿Cómo debe registrarse una devolución para que el mes cuadre?
Como su propio recibo de devolución que haga referencia al UUID de la venta original, no como una línea negativa dentro del libro de ventas. La devolución no puede superar el importe original, y varias devoluciones parciales no pueden sumar más que el original. Mantenga la devolución en el recuento de documentos y compénsela solo en la fase de valor, de modo que el recuento de documentos y la cifra de ingresos respondan a preguntas distintas.
¿Cuánto tiempo deben conservarse los registros?
Las normas fiscales egipcias exigen por lo general conservar libros, registros y documentos justificativos durante cinco años, y los registros electrónicos cuentan como registros primarios. Conserve las cargas útiles de los recibos, los acuses de recibo de la autoridad, los errores de validación, las versiones corregidas y el papel de trabajo de conciliación, no solo las copias del cliente. Confirme con su asesor fiscal egipcio el periodo que se aplica a su entidad, ya que el perfil del negocio puede cambiar la respuesta.
¿Puede esta herramienta enviar recibos a la ETA por mí?
No. El envío, la firma y la validación se realizan en la integración con el POS o el ERP que contiene las credenciales del dispositivo y la secuencia. La herramienta captura los datos de los documentos que ya tiene, incluidos los recibos impresos, los informes de sucursal y las pantallas de estado guardadas, y los coloca en una sola tabla para poder comparar las tres poblaciones. No sustituye a la integración ni determina si un documento es conforme.
El cambio útil es pequeño. Una vez que las tres poblaciones están en una sola tabla con una clave declarada y una base de fecha declarada, una diferencia deja de ser una discusión de fin de mes y se convierte en una fila con una causa asociada. Empiece con una sucursal y un mes: extraiga el informe de cierre diario, la exportación del libro mayor y la pantalla de estado, escriba las doce columnas una vez y vea cuántas de las diferencias se resuelven antes de que alguien abra un portal. Procese un mes de recibos con el flujo de trabajo por columnas y cuente cuántas filas se resuelven en un solo documento.