Principios

POST /api/v1/ecf no espera un calco del XML que la DGII exige. El e-CF real tiene cerca de 137 campos de encabezado y una matriz de obligatoriedad distinta por cada uno de los 10 tipos de comprobante, y ningún integrador debería tener que conocer eso de memoria para emitir una factura. Por eso el payload que recibe NovaFE es un modelo curado: le describes tu intención comercial (quién te compró, qué le vendiste, cómo te pagó) y NovaFE arma el e-CF conforme a partir de ahí.

Esta página explica esa división de trabajo. Los módulos siguientes cubren cada bloque del payload campo por campo.

Lo que arma NovaFE

Por defecto no lo mandas en el payload, porque NovaFE ya lo resuelve por su cuenta. La excepción es la numeración, que puedes asumir tú (ver la sección Numeración propia de e-NCF y secuencias):

Campo del XML	De dónde sale
<eNCF>	Asignación atómica desde tu rango de secuencias autorizado. Con numeración propia, lo envías en encf.
<FechaVencimientoSecuencia>	Del rango asignado. Ausente en los tipos 32 y 34, que no vencen. Con numeración propia, la envías en sequenceExpiresOn.
<RNCEmisor>, <RazonSocialEmisor>, <NombreComercial>	De tu tenant.
<DireccionEmisor>, <Municipio>, <Provincia>, actividad económica	De tu perfil fiscal (Cabecera y comprador explica esto).
Todos los <Totales> y <MontoItem>	Calculados a partir de tus líneas y tus ajustes.
<IndicadorNotaCredito>	La regla de los 30 días desde la fecha del comprobante que referencias.
<FechaHoraFirma>, <Signature>, código de seguridad, QR	Se generan al firmar con tu certificado.

Lo que mandas tú

Comprador, líneas, forma de pago, tipo de ingreso, ajustes globales de la Sección D, referencia a otro comprobante (para notas de crédito o débito), montos ya convertidos si facturas en otra moneda, y datos de embarque, transporte o paginación cuando el tipo de comprobante los admite. El detalle de cada bloque está en los módulos siguientes:

• Cabecera y comprador
• Pago y líneas
• Ajustes, referencia y moneda extranjera
• Embarque, transporte y paginación

Qué campos son obligatorios depende del tipo de comprobante: eso vive en la matriz de obligatoriedad por tipo.

El escape para migraciones: declaredTotals

Si estás migrando desde un sistema que ya calcula sus propios totales, puedes mandarlos igualmente en declaredTotals (a nivel de encabezado) y en lines[].declaredAmount (a nivel de línea). NovaFE los compara contra lo que él mismo calculó, con una tolerancia de un peso por campo en el encabezado y por línea.

Nunca rechaza por esto

Si tus totales declarados no cuadran con los de NovaFE dentro de esa tolerancia, la respuesta trae un toleranceWarning y probablemente la DGII acepte el comprobante como “aceptado condicional”. Nunca se rechaza el comprobante por esta diferencia: los valores que calcula NovaFE son siempre los que van al XML, así que el comprobante que le llega a la DGII es correcto de todas formas.

Este mecanismo existe para que una migración no se trabe reconciliando centavos de redondeo entre dos motores de cálculo distintos, no para que ignores los totales que NovaFE calcula.