Chequeos de datos a XML antes de firmar un e-CF: decimales y obligatoriedad

Por qué el chequeo local antes de la firma merece su propio momento

Cuando un POS dominicano emite un e-CF, lo que ves en pantalla no siempre es lo que viaja al XML firmado. El Informe Técnico e-CF v1.0 de la DGII (marzo 2026, publicación informativa sin validez legal) describe, en §4, que los distintos comprobantes electrónicos se transmiten como comunicaciones XML construidas sobre su esquema XSD correspondiente (DGII, Informe Técnico e-CF v1.0). El responsable de la firma, según §3, es el emisor a través de su certificado; el responsable de la aceptación fiscal es la DGII. Entre uno y otro está la serialización local del XML, una capa de ingeniería que conviene revisar antes de firmar.

Por eso, antes de firmar y enviar, conviene pedirle al proveedor una matriz de aceptación local con datos ficticios. Lo que el proveedor demuestre sobre esa matriz es lo que se sabrá con claridad sobre esa capa. Lo que la DGII haga después lo decide la DGII.

Cómo separar el formato de pantalla del formato de transmisión

Tu POS muestra "1,250.50" porque así lo lee un humano en pantalla. Lo que el campo numérico del XML espera, según §11.1.2 del informe, es una cadena con punto decimal y sin separador de miles, donde "1250.50" representa el mismo valor subyacente que la pantalla muestra como "1,250.50". La diferencia entre uno y otro es de presentación, no de cantidad.

Para verificarlo se pide al proveedor un caso sintético donde el valor subyacente es el mismo. El comprobante ficticio usa un monto de "1,250.50" en pantalla y, en el XML resultante, la cadena numérica correspondiente refleja "1250.50" como representación ilustrativa del mismo valor; el chequeo confirma que lo que ves es lo que viaja, conservando el monto. Los nombres y montos concretos del campo y su forma exacta de serialización dependen de la documentación del Formato e-CF que aplique al comprobante que vas a emitir. Esto no es cálculo de ITBIS ni conversión de moneda; es probar que pantalla y transmisión coincidan sin alterar el valor.

El propio §13, nota al pie del informe, abre excepciones por campo, así que la cantidad de decimales, el manejo de moneda y otros detalles de precisión los revisa tu proveedor fiscal con tu contador contra la documentación técnica de ese campo. Este chequeo solo verifica que pantalla y transmisión coincidan sin alterar el valor.

Escapar caracteres reservados sin reescribir el nombre del negocio

Los nombres comerciales pueden incluir símbolos que el estándar XML trata como reservados, según §11.1.2 del informe: &, <, >, comillas, entre otros. Si el serializador los manda crudos sin la representación adecuada, el documento puede quedar mal formado. La solución que describe §11.1.2 consiste en sustituir esos caracteres por referencias numéricas estándar, por ejemplo & para & y < para <, entre las referencias previstas por el estándar.

Lo que el chequeo verifica es que ese reemplazo sea mecánico, no editorial. Si el cliente ficticio se llama Taller A & B, la representación esquemática en el XML se ve como Taller A & B (campo y nombre son ilustrativos; los nombres reales de campos y elementos dependen de la documentación del Formato e-CF que aplique). Lo que NO debe pasar es que el integrador cambie el nombre por Taller A y B, quite acentos o "limpie" el texto hasta hacerlo irreconocible. Eso es perder información del negocio para resolver un problema que era de sintaxis.

Basta un cliente ficticio con un nombre que contenga & y, si quieres, un acento. El XML resultante tiene que poder decodificarse de vuelta al texto original. Si al decodificar no coincide, el chequeo falla. Pide al proveedor comprobar que la serialización cumple las especificaciones aplicables y conserva el texto original al interpretarlo.

Códigos de obligatoriedad 0/1/2/3 sin inventar reglas

El §11.1.1 del informe define cuatro estados para un campo según el tipo de e-CF:

• 0 — no corresponde: el dato no debe ir en ese tipo de comprobante.
• 1 — obligatorio: el dato siempre está presente, con independencia de las características de la operación.
• 2 — condicional: puede ser obligatorio cuando se cumple una condición prevista en el Formato e-CF que aplica.
• 3 — opcional: puede incluirse según corresponda.

Los códigos conservan esos significados; lo que cambia es el código asignado a cada campo según el tipo de e-CF y la condición documentada. Cada campo se evalúa contra el Formato e-CF aplicable, con revisión del proveedor fiscal y del contador cuando corresponda.

Una salida razonable del chequeo local es una lista corta: para el tipo de e-CF y la operación concretos, la presencia o ausencia de cada campo documentado debe coincidir con lo que indica su código 0/1/2/3 y, cuando aplique, con la condición que activa el 2. Esa lista se acuerda por escrito con tu proveedor fiscal y tu contador antes de salir a producción; este artículo no exige una firma específica del proveedor como requisito.

Matriz de aceptación sintética: preguntas, respuestas y significado del PASS

La siguiente matriz es ilustrativa: usa exclusivamente datos ficticios y documentos locales sin firmar ni enviar. El proveedor debe seleccionar las reglas documentadas del tipo de e-CF que se quiere probar, sin convertir este ejemplo en una emisión real.

Chequeo	Pregunta que haces	Lo que esperas ver	Resultado esperado
Formato numérico	Si el POS muestra "1,250.50", ¿qué cadena va al XML?	La cadena numérica refleja "1250.50" como representación ilustrativa del mismo valor	PASS si conserva el valor previsto y cumple el formato y la precisión documentados del campo
Escape de texto	Si el cliente se llama Taller A & B, ¿qué cadena va al XML?	Por ejemplo, Taller A & B; al interpretar el XML se recupera Taller A & B	PASS si la decodificación devuelve el nombre exacto
Obligatoriedad	Para el tipo y operación seleccionados, ¿cuándo corresponde el campo documentado?	La presencia o ausencia del campo coincide con su código 0/1/2/3 y, cuando aplique, con la condición que activa el 2	PASS si presencia/ausencia coincide con la documentación

PASS significa que el serializador superó los chequeos locales acordados sobre requisitos documentados, aplicados sobre los datos ficticios que definiste. No significa que el XML local sea correcto en su totalidad, que la DGII vaya a aceptar el comprobante, ni que la próxima factura real vaya a pasar. Es, en el mejor de los casos, la confirmación de que el conector entiende los chequeos locales acordados sobre requisitos documentados antes de que algo real se firme.

Cómo Antreva Tech puede ayudar en este tramo

En Antreva Tech proponemos un alcance acotado a la capa de ingeniería entre tu POS y la firma del e-CF (solución e-CF y POS), sin intervenir la interpretación fiscal ni la decisión de aceptación de la DGII.

Bajo un acuerdo previo, podemos revisar contigo: mapear los campos de tu POS al documento e-CF que te corresponde, mantener la cadena formateada para pantalla separada del valor numérico que viaja al XML, diseñar casos de regresión sintéticos que ejerciten los tres chequeos antes de cualquier firma, y dejar documentada una checklist de aceptación acordada con tu proveedor y tu contador.

La intención es ayudarte a detectar a tiempo cambios de formato en la serialización local antes de que afecten la operación; no garantiza resultados fiscales ni reemplaza la validación oficial.

La interpretación de cada código de obligatoriedad, formato y excepción se mantiene con tu proveedor fiscal y tu contador; la DGII determina la aceptación final.

Si algo se desvía después, el recorrido por capas antes de abrir un ticket está en cómo clasificar la capa fallida del e-CF.

Si quieres conversar sobre cómo revisar tu flujo de datos y serialización XML antes de firmar, escríbenos desde la página de facturación electrónica, CRM, POS y negocios.

Preguntas frecuentes

¿Un PASS local significa que la DGII va a aceptar el e-CF?

No. El PASS local prueba únicamente los chequeos definidos sobre datos ficticios. La aceptación del comprobante la determina la DGII mediante su validación oficial; la mera recepción del comprobante no implica aceptación.

¿Por qué no pedirle al proveedor "todos los numéricos a dos decimales"?

Porque el propio informe (§13, nota al pie) admite excepciones por campo. Los requisitos de precisión concretos los confirma tu proveedor fiscal con tu contador contra la documentación técnica del campo.

¿Esto sustituye la validación oficial del comprobante?

No. Es una verificación local con datos sintéticos antes de firmar. La validación oficial la conduce la DGII por el canal y con la evidencia que aplique.