La facturación electrónica se explica casi siempre desde el lado del trámite: qué formulario, qué plazo, qué multa. Para quien tiene que operar todos los días, el trámite es lo de menos. Lo que importa es entender qué está pasando por debajo, porque de ahí salen casi todos los problemas.
Un comprobante electrónico es un archivo con estado
Cuando emites una factura electrónica no imprimes un papel: generas un archivo estructurado, se firma digitalmente y se envía a la administración tributaria para que lo valide. SUNAT responde, y esa respuesta es lo que convierte el archivo en un comprobante válido.
De ahí sale la idea más importante de todo este asunto: un comprobante electrónico no es solo un documento, es un documento con un estado. Emitido no es lo mismo que aceptado, y aceptado no es lo mismo que aceptado con observaciones. Un sistema que solo te enseña el PDF y no el estado te está ocultando la mitad del dato.
El proveedor homologado y por qué existe
Entre tu sistema y SUNAT suele haber un intermediario homologado. Se encarga de la firma, del formato y del diálogo con la administración, y devuelve el resultado. No es un lujo: es la pieza que absorbe los cambios de formato de la administración para que tu sistema no tenga que reescribirse cada vez que cambia una versión de catálogo.
Lo que sí conviene exigirle a tu sistema de gestión es que guarde ese resultado junto al documento. Si la respuesta vive solo en el portal del proveedor, cada consulta futura es una investigación.
Los catálogos son la fuente silenciosa de errores
SUNAT publica catálogos con los códigos válidos para muchas cosas: tipo de operación, motivo de una nota de crédito, motivo de traslado en una guía de remisión, modalidad de transporte. Cada uno tiene su propio dominio de valores, y no son intercambiables aunque se parezcan.
El error clásico es enviar un código correcto del catálogo equivocado. El documento sale, el sistema no se queja y el rechazo llega después. Por eso una plataforma de gestión debería mantener los catálogos actualizados y ofrecerlos como una lista cerrada, no como un campo de texto libre donde alguien escribe lo que recuerda.
Qué hacer cuando el envío falla
Falla. Se cae la conexión, el proveedor tiene mantenimiento, un campo del cliente está incompleto. Lo importante no es evitar el fallo, es qué queda cuando ocurre: el documento tiene que existir antes del intento de envío, su estado tiene que verse en la lista y el reintento no puede consumir un segundo número de la serie. Si el fallo obliga a rehacer la venta desde cero, el problema técnico se convierte en un problema de caja y de cola en el mostrador.
Lo que hace XEN con un comprobante pendiente, rechazado o emitido sin conexión está respondido, pregunta por pregunta, en el centro de ayuda. Ver las respuestas sobre comprobantes
Boleta, factura y nota: para qué sirve cada una
La factura se emite a quien necesita sustentar crédito fiscal y exige identificación tributaria del comprador. La boleta se emite al consumidor final. La nota de crédito corrige o anula un comprobante ya emitido, y la nota de débito lo incrementa. Ninguna de las cuatro se sustituye por editar el documento original: una vez aceptado, el original ya no se toca.
Esa es la razón por la que una gestión bien hecha no permite editar una factura enviada. No es rigidez del software: es que el documento ya existe fuera de tu sistema.
Lo que deberías poder responder en cualquier momento
Si tu sistema está bien montado, estas preguntas se responden en segundos y sin llamar a nadie: cuántos comprobantes emití este mes, cuántos siguen pendientes ante SUNAT, cuál fue el motivo del último rechazo y qué serie está usando cada caja. Si alguna exige abrir un portal externo o una hoja de cálculo, ahí tienes el hueco.
La facturación electrónica no es difícil de entender. Es difícil de sostener cuando el sistema trata el comprobante como una impresión y no como lo que es: un documento vivo con un estado que otra institución también conoce.
