Un mensaje puede armar la factura.
Emitirla sigue siendo decisión suya.

La regla que no se negocia

Nunca audio → Hacienda. Siempremensaje o audio → estructura → borrador → confirmación de una persona → emisión.

El motivo es que un comprobante electrónico es un documento legal con consecuencias tributarias, y gasta un consecutivo que no se puede devolver. Un sistema que interpreta «facturale tres mil a Juan» y emite directamente va a acertar muchas veces y a equivocarse algunas, y las equivocaciones no se corrigen borrando: se corrigen con una nota de crédito, que es otro documento fiscal. Poner una confirmación humana entre la interpretación y la emisión no es desconfianza del modelo; es la única forma de que el error sea barato.

Qué resolvería la primera versión

• Crear un borrador a partir del mensaje.
• Mostrarlo completo: receptor, líneas, impuestos y total, sin resumir lo que hay que revisar.
• Editarlo antes de confirmar.
• Confirmar, que es el momento en que se emite y no antes.
• Consultar el estado del comprobante.
• Recibir el PDF y el XML por el mismo canal.

Lo difícil no es entender el mensaje

Es saber quién escribe. Un número de teléfono tiene que resolverse a una persona, a sus permisos y a una empresa activa —y quien trabaja con varias empresas puede tener acceso a más de una—. Emitir con la empresa equivocada produce un comprobante válido a nombre de quien no corresponde, que es peor que no emitir.

Por eso esto es una interfaz conversacional sobre el mismo núcleo que usa la aplicación, no una integración aparte con sus propias reglas.

Por qué «en investigación» y no «planeado»

Porque hay dos cosas que no dependen de nosotros y pueden cambiar la respuesta: la aprobación de Meta para el tipo de uso que esto requiere, y el costo por conversación del canal, que define si el modelo cierra. Las dos se investigan antes de comprometer una fecha, y el resultado puede ser que no se construya.