Inicio / CFDI 4.0
La facturación de un hotel no es la de una tienda: hay impuesto estatal, hay huéspedes que no piden factura y hay una factura global a fin de mes que tiene que cuadrar con la caja.
Hay tres cosas que un sistema genérico casi siempre hace mal en hotelería: el impuesto estatal sobre hospedaje, la factura global de quienes no pidieron comprobante, y la relación entre lo que se cobró en caja y lo que se timbró.
| Pieza | Estado | Detalle |
|---|---|---|
| PAC | En producción | Digifact. Cada hotel carga sus propias credenciales y elige ambiente de pruebas o producción. |
| CFDI 4.0 de ingreso | En producción | Concepto por concepto, con uso de CFDI, régimen fiscal y código postal del receptor validados antes de enviar. |
| ISH | En producción | Impuesto local por estado, configurable por propiedad. |
| Factura global | En producción | Del periodo, con la información de las estancias que no pidieron comprobante. |
| Cancelaciones | En producción | Con motivo de cancelación y, cuando corresponde, el folio que sustituye. |
En el onboarding se pasa a producción y se timbra un comprobante de prueba real contigo presente. No entregamos «ya quedó configurado» por correo.
Un timbrado correcto es sólo la mitad. La otra mitad es poder demostrar, meses después, que lo que se cobró y lo que se facturó son la misma operación: el folio de la estancia, el movimiento de caja y el CFDI apuntan al mismo lugar, y la bitácora dice quién tocó qué.
La guía completa —uso de CFDI, complemento de pago y cancelaciones— está en CFDI 4.0 para hoteles.
Timbrado vía PAC (Digifact), desglose por concepto —hospedaje y consumo con su propia clave—, ISH fuera de la base de IVA, factura global del mes, cancelación con motivo y XML archivado en bucket privado.
El cajero cuenta el efectivo primero y el sistema compara después. Si hay diferencia, el corte queda pendiente de autorización de un administrador con PIN, y el reparto de propinas solo aparece en el paso final.
Auditoría impredecible del 30% de las habitaciones ocupadas, con selección aleatoria en base y registro inmutable. El sorteo mete además las que tienen estancia activa aunque su estado no lo diga, que es justo el fraude que persigue. Revela qué cuartos concentran problemas.
El frente de la INE trae los datos impresos y el nombre se contrasta contra lo que la CURP codifica; el reverso queda como verificación, porque su zona de lectura mecánica trae dígitos de control — eso convierte «creo que dice 740812» en «dice 740812, o el renglón está mal y lo sé». Guardar la imagen viene apagado de fábrica: si la propiedad la conserva, va cifrada AES-256-GCM con llave por hotel, cada consulta queda en bitácora y la foto se borra sola al cumplirse el plazo de retención que ella fija. Y la captura manual nunca desaparece. Donde el huésped deja sus datos —el escáner y el motor de reservas— aparece el aviso de privacidad del hotel, con el enlace a su aviso integral.
Cuáles campos son obligatorios se configura por hotel — los de vehículo, conductor y domicilio no vienen de la norma sino de reglamento local. Domicilio y llegada se capturan durante el propio check-in —el plegable del domicilio se abre solo al escanear la INE— y lo que falte se completa después, guardando qué campos se tocaron, quién y cuándo.
Contar personas sirve para cobrar, no para contestar. A las 3am siempre existe «registrar sin identificación» con motivo: el contrapeso es la lista de registros incompletos, no un check-in detenido.
Super Admin, Admin, Gerente, Recepcionista, Supervisor de limpieza, Valet, Bartender/Mesero, Cocina, Camarista, Mantenimiento y Monitoreo — cada acción validada del lado del servidor. El gerente manda en su propiedad y no sale de ella.
Retirar efectivo del cajón, cancelar una reserva que sí llegó, reimprimir un corte o el comprobante de un cobro, recorrer la hora de entrada, dejar «disponible» un cuarto que se rentó por fuera, dar por buena la diferencia de un corte, regalar un upgrade, anular un consumo, autorizar un descuento, iniciar Control Sorpresa y asentar sus discrepancias, y los dos borrados ARCO. Son catorce, ninguna deja rastro por sí sola, y aquí las catorce piden PIN de administrador y motivo escrito, y guardan quién lo pidió y quién lo autorizó en el mismo renglón. También sin red: el PIN se verifica en el aparato y el renglón queda marcado «PIN verificado sin red».
Row-Level Security forzado en PostgreSQL: cada hotel solo ve sus datos, incluso al cambiar de propiedad. Re-verificado con pruebas dedicadas.
El Manual Técnico de la PUI (DOF 23/01/2026) describe el lado de la institución, y ese lado está hecho en INNKEY. Funciona al revés de como suele contarse: no se transmiten los huéspedes. La Plataforma manda la CURP de una persona buscada, INNKEY consulta el padrón del propio hotel y solo notifica si hay coincidencia. De quien nadie está buscando no sale nada.
Dicho sin adornos: INNKEY no te certifica ni te da por cumplido. El software está listo; el trámite lo haces tú. Ni la Ley General ni el Manual Técnico mencionan la palabra «hospedaje» — un hotel entra, si entra, por una cláusula general. Por eso pedir identificación a cada ocupante se configura por hotel y jamás detiene un check-in.
Treinta minutos por videollamada con tu propia operación: check-in, corte de caja, restaurante y reservas web. A la mitad apagamos la red y seguimos.
Agenda la demo sin internet