Configuración e-CF

Centraliza los datos fiscales del emisor, el certificado digital P12, las secuencias e-NCF, los pasos de la certificación DGII y la habilitación PROD vía Delegación de Roles.

Checklist: qué necesita un tenant para certificarse

Revísalo antes de crear la postulación. Cada punto que falte aparece después como un bloqueo en medio del proceso, y varios pasos de la DGII se reinician ante cualquier rechazo.

Ante la DGII (fuera de la app)

• [ ] RNC activo y al día con las obligaciones tributarias (declaraciones y pagos). La DGII lo comprueba al final, en «Verificación de estatus»: una omisión abierta detiene la certificación en el último paso.
• [ ] Clave de Oficina Virtual (OFV) de la empresa, y acceso al Buzón: ahí llega la invitación al Portal de Certificación y las respuestas de cada paso.
• [ ] Solicitud de Emisor Electrónico presentada en OFV (formulario FI-GDF-016). La DGII responde por el Buzón con el acceso al portal de certificación.
• [ ] Certificado digital para Procedimiento Tributario vigente, emitido por una entidad certificadora autorizada (Viafirma, Avansi/Digifirma, Cámara de Comercio), en archivo .p12 con su contraseña. Puede ser de la empresa o de su representante (persona física).
• [ ] Si el certificado es de una persona física y el RNC es de una empresa: hacer la Delegación de Roles de Facturación Electrónica en OFV (el representante delega al RNC). No bloquea la certificación, pero sin ella la autenticación en producción falla. Hazla temprano.
• [ ] Un correo que la empresa revise: la DGII avisa por el Buzón, y la app envía la copia de los e-CF al correo del emisor.

En la app (Fase 0 del asistente los valida solos)

• [ ] P0.1 Certificado P12 cargado en Config e-CF, con contraseña; el sistema extrae vigencia y titular. Quien lo carga debe ser dueño o administrador del tenant (la clave privada no está al alcance de otros roles).
• [ ] P0.2 Datos del emisor completos: RNC, razón social, nombre comercial, dirección (obligatoria en el XML), teléfono, correo. Municipio y provincia solo viajan como código DGII de 6 dígitos; si no los tienes, déjalos vacíos.
• [ ] P0.3 Postulación firmada con el P12 y subida al portal. La app la firma; tú la subes.
• [ ] P0.4 Delegación (ver abajo). Bloquea "Activar Producción" cuando el certificado es personal y el RNC corporativo: el botón no se habilita sin el acuse de aprobación, y el servidor lo rechaza aunque se intente por otra vía. No afecta a las pruebas de certificación.
• [ ] Secuencias e-NCF de certificación: un rango activo por cada uno de los 10 tipos (31, 32, 33, 34, 41, 43, 44, 45, 46, 47), con fecha de vencimiento (el XML la lleva). Se registran con un clic desde el asistente del Paso 4 (botón Registrar secuencias de certificación: rango 100 a 10,000,000 por tipo, vigentes dos años; el 100 deja margen a los e-NCF fijos del Set de Pruebas). Si un tipo tiene un rango activo vencido o agotado, anúlalo primero en Secuencias e-NCF. El cierre de certificación las anula todas.
• [ ] Contactos: al menos un cliente con RNC (o el botón «Usar a Khaostozen como cliente de simulación»), el consumidor final y un contacto extranjero para 46/47 (o su botón de simulación). El asistente del Paso 4 te lo pide si falta.
• [ ] Catálogo con al menos un servicio o producto con precio. Si está vacío, el asistente usa una línea genérica de simulación.
• [ ] Nombre y versión del software para la postulación: Simpli5CRM y la versión que muestra el pie de la app.

Durante el proceso

• [ ] Los pasos 2, 3 y 4 se reinician enteros ante un solo rechazo, y el 8 ante un fallo de recepción. Emite con el asistente, no a mano, y no subas al portal archivos que no salgan del panel correspondiente. Si la DGII reinició un paso, usa Reiniciar el Paso N en ese mismo paso (solo dueño o administrador): la app retira los documentos de prueba de ese paso y de los posteriores, manda a la Papelera las facturas de simulación (no se restauran: son documentos de prueba) y vuelve al paso reiniciado. Los asientos contables de prueba se conservan como evidencia. Antes esto exigía tocar la base de datos.
• [ ] Los pasos 6, 11 y 14 los resuelve la DGII a su ritmo (días). El asistente los marca con «Avanzar» cuando el portal confirme.
• [ ] Para los pasos 7 a 11 (recepción), las URL de servicios las genera la app; la DGII envía documentos de prueba a esas URL y la app responde sola.
• [ ] Al terminar: Activar Producción en la app purga los documentos de prueba (e-CF emitidos y recibidos, aprobaciones comerciales enviadas y recibidas), borra los asientos de prueba que quedaron en borrador en Contabilidad, anula las secuencias de certificación y retira las facturas de simulación. Después registra los rangos e-NCF de producción que te apruebe la DGII.

Cómo usarlo

1. Certificado Digital P12 — sube el .p12 que te entregó la entidad certificadora (Viafirma, Avansi, etc.) y guarda su contraseña. Queda encriptado en el vault de Supabase.
2. Datos del Emisor — completa razón social, RNC, dirección, teléfono, email, régimen fiscal. Estos datos se inyectan en cada e-CF emitido, así que deben cumplir el formato de la DGII: teléfono 809-555-1234, correo sin guion bajo ni espacios (máximo 80 caracteres), razón social hasta 150 caracteres y dirección hasta 100. Si no cumplen, la emisión se detiene antes de tomar el número y te dice qué corregir.
3. Postulación DGII — baja el XML de Postulación desde el portal de certificación DGII, súbelo aquí, fírmalo con el P12 y descarga el firmado para subirlo al portal.
4. Delegación de Roles e-CF — paso post-certificación obligatorio cuando el cert es personal y el RNC corporativo. Sin esto, ValidarSemilla en PROD rechaza la autenticación.
5. Ambiente DGII — readonly. Indica si este tenant emite contra TEST, CERT o PROD. Se activa automáticamente vía el closeout (botón Activar Producción) tras completar las pruebas DGII; no se cambia a mano.
6. Secuencias e-NCF — agrega los rangos autorizados por DGII para cada tipo de e-CF (31, 32, 33, 34, 41, 43, 44, 45, 46, 47). Durante la certificación no hace falta escribirlos: el asistente del Paso 4 los registra con un clic. Solo puede haber un rango activo por tipo; los anulados, vencidos o agotados se conservan como historial y no estorban al siguiente. Las secuencias (e-NCF y NCF serie B) solo las registra y anula un Propietario o Administrador. El contador de cada rango lo avanza únicamente el sistema al emitir: nadie puede retrocederlo ni adelantarlo, y un rango que ya entregó comprobantes no se borra — se anula y se registra uno nuevo.
7. API Keys (e-CF como servicio) — emite claves para que sistemas externos consuman tu emisor vía la API REST. Solo un Propietario o Administrador puede crearlas o revocarlas: una clave de producción emite comprobantes fiscales reales.
8. Parámetros Operativos — ITBIS por defecto y Modo Sandbox (intercepta envíos a DGII y devuelve respuestas ficticias para entrenamiento).

Delegación de Roles e-CF (post-certificación)

Si tu certificado es personal (Persona Física) y emites en nombre de un RNC corporativo, DGII exige que el RNC delegue formalmente los roles de Facturación Electrónica al titular del cert. Sin esta delegación registrada en el ambiente PROD, la autenticación contra ValidarSemilla falla con HTTP 400 y un HTML genérico (<h2>ERROR: </h2>), porque DGII rechaza la petición en su capa de infraestructura antes de llegar a la aplicación.

Flujo end-to-end (5 pasos resumidos):

1. En la OFV personal del representante legal, ve a Delegación de e-CF → Delegación de Roles. Busca tu cédula, marca los 4 roles (Administrador, Firmante, Solicitante, Aprobador), acepta los términos y descarga el XML.
2. Sube el XML al bloque Delegación de Roles e-CF de esta pantalla y presiona Firmar con P12. La plataforma firma con el mismo certificado del vault y te descarga el XML firmado.
3. Vuelve a la OFV → Delegación de e-CF → Carga XML Delegación, sube el _firmado.xml y guarda.
4. Ve al Buzón de la OFV personal, abre los mensajes "Delegación de Rol de Facturación Electrónica" y acepta cada rol.
5. Vuelve a esta pantalla, al bloque P0.4, y marca Aprobada en buzón OFV. Ese acuse es el que desbloquea "Activar Producción".
6. Verifica en Consulta de Delegaciones que los 4 roles aparezcan aprobados.

Después, prueba la conexión en Monitor DGII → Probar Conexión a DGII. Debe devolver un token en lugar del 400 ERROR.

Qué verifica la plataforma al firmar

Antes de firmar, lee el XML que descargaste y lo contrasta con tu configuración:

• Que la empresa del archivo sea el RNC del emisor que tienes configurado.
• Que la persona delegada sea la del certificado cargado.
• Que los cuatro roles estén marcados en la OFV.

Si algo no cuadra, no firma y te dice exactamente qué campo. Si el archivo no se puede leer (por ejemplo, porque la DGII cambió el formato), firma igual y te avisa.

Re-firmar retira la aprobación. Si vuelves a firmar la Delegación —porque cambiaste de certificado o descargaste un archivo nuevo—, el acuse se borra y hay que volver a aprobar en el buzón. La autorización de la DGII va atada al certificado que firmó, así que heredar la aprobación anterior sería afirmar algo que no se verificó.

Si ya estás en Producción y te falta la Delegación

El bloque P0.4 sigue disponible después de certificarte: ábrelo desde el asistente («Emisor Certificado DGII → Ver detalles → Fase 0») y completa el flujo de arriba. Mientras falte, la pantalla muestra un aviso permanente, porque la DGII rechaza cualquier emisión hasta que la delegación esté aprobada.

Guía detallada paso-a-paso (incluye screenshots, errores comunes, troubleshooting): ver docs/dgii-activacion-prod.md — playbook completo para clientes nuevos.

Validación automática P12 ↔ Delegación

Probar Conexión a DGII compara la huella SHA-1 del certificado P12 actual contra la huella del cert que firmó tu última Delegación FE registrada in-app, y muestra el resultado como step delegacion:

• ✅ OK — las huellas coinciden, la Delegación está alineada con el cert actual.
• ⚠ Warning "P12 actual ≠ cert que firmó la Delegación" — renovaste el .p12 o subiste otro y la Delegación quedó atada al cert anterior. DGII vincula la autorización a la huella del cert, no al sujeto, así que la delegación está huérfana. Solución: rehaz el flujo Delegación de Roles (pasos 1–5) con el cert actual.
• ⚠ Warning "Sin Delegación FE registrada in-app" — no hay evidencia firmada por la plataforma. Si firmaste con la App Firma DGII externa no podemos verificar coincidencia; sube el XML aquí y fírmalo nuevamente para registrar la evidencia.

¿Este RNC recibe e-CF? (Monitor DGII)

En Monitor DGII, debajo de Probar Conexión a DGII, escribe un RNC (9 dígitos) o una cédula (11) y pulsa Consultar. La plataforma le pregunta al directorio de receptores electrónicos de la DGII si ese contribuyente recibe comprobantes electrónicos y en qué dirección. Solo consulta: no emite ni envía nada.

La respuesta tiene tres resultados posibles, y cada uno se ve distinto:

Según el ambiente:

• Producción — la respuesta es la real.
• Pruebas (TesteCF) — la DGII responde con un receptor simulado suyo para cualquier RNC. Se marca con un aviso: sirve para ensayar, no es el receptor real.
• Certificación (CerteCF) — la DGII no tiene este servicio en ese ambiente. El recuadro aparece deshabilitado con la explicación.

Necesita tu certificado P12 vigente: la consulta se hace con el mismo acceso que usas para emitir.

Modo Sandbox / Entrenamiento

Cuando está activo, todo envío a DGII para este tenant se intercepta y devuelve respuestas ficticias (TrackId con prefijo MOCK-, asientos contables marcados [MOCK_QA_SUBMIT]). Sirve para entrenar usuarios sin riesgo fiscal. Apagar antes de salir a producción real — combinarlo con ambiente PROD genera la trampa silenciosa de "crees que emites y nada llega a DGII".

Permisos

• owner / firm_admin / accountant — pueden editar todos los campos y firmar XMLs.
• cashier / sales — solo lectura.

Preguntas frecuentes

¿Cómo se firma la Declaración Jurada (Paso 13)? En el portal de la DGII pulsa «Generar archivo» y descarga el XML. En Config e-CF, abre el Paso 13, sube ese XML y pulsa «Firmar»: la app lo firma con el certificado que ya tienes cargado, igual que hizo con la Postulación. Descarga el archivo firmado y súbelo en el portal con «Enviar archivo». El Paso 14 lo resuelve la DGII comprobando que tu RNC está al día.

Las Fases 1, 2 y 3 me salen «Bloqueada». ¿Es por la Delegación de Roles?

No. La Delegación (P0.4) solo condiciona el paso a Producción, nunca las pruebas de certificación — puedes gestionarla cuando termines. Lo que abre las fases 1-3 es P0.1 Certificado + P0.2 Datos del Emisor + P0.3 Postulación. Si las ves bloqueadas, revisa cuál de esos tres está incompleto.

Dice que suba el certificado, pero yo sé que ya está cargado.

Si entraste con una cuenta invitada y no eres el dueño, necesitas rol de administrador para leer el certificado: es la clave privada de firma y no está al alcance de todos los miembros. Pide al dueño que te cambie el rol. La pantalla te lo indica cuando detecta que el certificado existe pero tu cuenta no lo alcanza.

¿Por qué ValidarSemilla en PROD me devuelve 400 con HTML genérico?

99% del tiempo es porque falta la Delegación de Roles del cert personal hacia el RNC corporativo en el ambiente PROD, o porque renovaste el P12 y la Delegación quedó atada al cert anterior. Haz el flujo de Delegación arriba; el step delegacion de Probar Conexión te avisa si hay mismatch de huella.

¿Cómo distingo "delegación faltante" de "XML mal formado"?

Por el Content-Type de la respuesta DGII: si es text/html con <h2>ERROR: </h2> y headers reducidos (sin set-cookie citrix_ns_id), DGII rechazó en infraestructura → falta delegación o el cert no está autorizado. Si es application/json con {mensaje, errores}, llegó a la app → revisar el XML/firma.

¿Puedo firmar el XML de Delegación con la App Firma DGII en lugar de la plataforma?

Sí, pero no hace falta. La plataforma usa el mismo XMLDSig estándar (RSA-SHA256, C14N, SHA-256) que la App Firma — el resultado es equivalente.

¿La firma se rehace cada vez que cambio de ambiente?

No. La firma es independiente del ambiente. La delegación que registrás en PROD vale sólo para PROD, y la de CERT sólo para CERT.

En el Paso 4 no encuentro dónde subir el Set de Pruebas.

No hay archivo. El Paso 4 se emite como facturas normales, con datos de tu

operación: son 25 comprobantes de 10 tipos distintos. El paso trae su propio

asistente de simulación: elige qué contacto hace de cliente, de consumidor

final y de extranjero (los selects vienen ya elegidos cuando no hay duda), revisa

el plan de las 25 facturas que arma con tu catálogo, y pulsa Emitir. Las crea

marcadas como simulación (número SIM-P4-…, nota «sin validez fiscal») y las

envía una por una en el orden del portal; se detiene en el primer rechazo y te

muestra el motivo. Lo ya aceptado no se repite al volver a pulsar. Al activar

producción, el cierre retira esas facturas del listado.

La tabla de arriba muestra las 11 casillas del portal (la factura de consumo se

parte en dos: de RD$250,000 en adelante y por debajo) y se va llenando a medida

que la DGII acepta. Solo cuentan los emitidos desde el CRM: los del Set de

Pruebas del Paso 2 no valen aquí aunque estén aceptados.

¿De verdad la DGII quiere datos «reales» en una certificación? Mi empresa es nueva y no tiene clientes.

«Datos de operaciones reales» quiere decir datos propios y verosímiles, no el

set de la DGII (ese fue el del Paso 2) ni clientes de verdad. En certificación la

DGII solo comprueba que el RNC del comprador exista; no valida quién es ni si es

tu cliente. Khaostozen certificó en abril de 2026 sin un solo cliente, con

compradores inventados sobre el RNC del contribuyente de pruebas de la DGII. El

asistente hace lo mismo: si no tienes contactos con RNC ni extranjeros, dos

botones crean los contactos de simulación que hacen falta, marcados como tales.

El cliente de simulación es Khaostozen Technologies SRL, la empresa de la

plataforma (RNC real y activo); solo si el tenant que certifica es Khaostozen se

usa el contribuyente de pruebas de la DGII, porque el emisor no puede ser su

propio comprador.

Subí un archivo en el Paso 2 y dice que es el del Paso 3.

La DGII entrega dos archivos parecidos. El del Paso 2 trae la hoja ECF con

los comprobantes que tú emites. El del Paso 3 trae ACEECF_Generadas: el

emisor es el contribuyente de pruebas de la DGII, tú eres el comprador, y trae la

columna FechaHoraAprobacionComercial. Ese va en el Paso 3.

¿Las facturas de simulación se pueden quitar del CRM?

Sí, en dos momentos. Cuando la matriz llega a 25 de 25, el asistente ofrece

enviarlas a la Papelera (salen de Facturación, KPIs y CxC; se pueden

restaurar). Mientras la matriz no esté completa hay que dejarlas: las notas 33 y

34 se cuelgan de las 31 aceptadas. Y al activar producción, el cierre de

certificación las elimina del todo, junto con los contactos de simulación y los

e-CF de prueba. La representación impresa del Paso 5 y las facturas de consumo

pequeñas para subir al portal no dependen de ellas: salen de los e-CF aceptados.

Paso 5: ¿de dónde salen las 11 representaciones impresas y en qué formato?

Del propio asistente, debajo del Paso 5: una fila por casilla del portal (31, 32

de 250K en adelante, 33, 34, 41, 43, 44, 45, 46, 47 y 32 por debajo de 250K),

tomando el e-CF aceptado del Paso 4 de cada tipo. Para la de consumo pequeña usa

la factura completa firmada al emitir, no el Resumen: ahí están las líneas y

el código de seguridad que valida el QR. El botón PDF abre la vista de

impresión: elige «Guardar como PDF». El portal admite hasta 10 MB en total.

Antes de subir, escanea el QR de cada una: debe abrir ConsultaTimbre y decir

«Aceptado». Marca en la fila si el QR validó.

¿Puedo crear las facturas a mano en vez de usar el asistente?

Sí, desde Facturación, con el tipo e-CF y el contacto adecuados (ver más abajo).

El asistente hace lo mismo, en el orden correcto y sin transcribir nada.

Antes de emitir el primero: registra las secuencias.

Cada tipo necesita un rango de e-NCF activo en Secuencias e-NCF (más abajo en

esta misma pantalla). Sin él, el envío falla con «Sequence error» y no llega a la

DGII. En certificación el rango es libre (1 a 10,000,000 por tipo); pon un

vencimiento porque el XML lo lleva y el esquema lo exige en casi todos los tipos.

El panel del Paso 4 te dice qué tipos siguen sin secuencia. Si ya emitiste

documentos del Paso 2 con números fijos, empieza el rango por encima de ellos:

en certificación un número usado no se repite.

¿Qué pasa con esas secuencias al activar producción?

El cierre de certificación las anula (quedan como «anuladas» para auditoría) y

purga los documentos de prueba. En Secuencias e-NCF ya no aparecen junto a las de

producción: se guardan plegadas bajo Rangos anulados, sin números disponibles,

porque ya no se pueden usar. Los rangos de producción los autoriza la DGII

después de certificar: regístralos entonces, con su vencimiento real.

¿Cómo se emite cada tipo desde Facturación?

Con el tipo e-CF correcto en la factura y el contacto adecuado:

• 31, 44, 45: contacto con RNC. Para el 45 tiene que ser una entidad del

Estado; para el 44, una empresa de régimen especial (zona franca, etc.).

• 32: consumidor final, con o sin RNC. Dos por RD$250,000 o más y cuatro por

menos; estas últimas mandan solo el Resumen y se suben a mano al final.

• 41: el «contacto» es el proveedor informal al que le compras (su cédula

va como RNC del comprador).

• 43: gastos menores. No lleva comprador; el contacto de la factura se

ignora.

• 46, 47: contacto extranjero, con tipo de identificación Pasaporte o

Tax ID y su identificador; el país se toma del contacto. Sin ITBIS. Si no

tienes ninguno, el asistente crea uno de simulación con un clic. El 47 solo

admite servicios y lleva retención de ISR; el 41 lleva retención de ITBIS e

ISR (el asistente las pone).

• 33 y 34: desde la factura ya aceptada, botones ND y NC en la lista.

Referencian ese documento; no se crean sueltas.

Las líneas sin ITBIS viajan como exentas; en la 46 todo va con ITBIS 0%.

El total del XML se recalcula desde las líneas y, si no cuadra con el de la

factura, el envío se detiene con un mensaje que muestra ambos montos.

¿En qué orden hay que emitirlos?

El portal lo fija y conviene respetarlo:

1. Los tipos 31, 32 (≥250K), 41, 43, 44, 45, 46 y 47.
2. Después las notas: 33 y 34 — referencian a los de arriba, así que no pueden ir antes.
3. Los Resúmenes de las facturas de consumo menores a 250K.
4. Y solo cuando esos Resúmenes estén aceptados, las facturas completas de esas mismas.

Aquí una secuencia rechazada se pierde.

A diferencia del Paso 2 —donde los e-NCF venían fijos en el Excel y se reintentaba

con el mismo— en el Paso 4 el número de un comprobante rechazado no se reutiliza:

el reintento va con el siguiente. Y cualquier rechazo reinicia el paso completo.

Emite despacio y revisa antes de enviar.

¿De dónde saco las facturas de consumo <250K que pide el último tramo?

Del propio asistente: en el Paso 4, debajo de la lista de aceptados, aparece un

botón por cada una. Ese archivo es el que se firmó al emitirla, y es el único que

el portal acepta — uno vuelto a firmar lleva otra hora y por tanto otro código de

seguridad, distinto del que ya viajó en el Resumen.

Subí el archivo del Set de Pruebas y me dice que no encuentra la hoja «ECF».

Son dos archivos distintos y se parecen. El del Paso 2 trae la hoja ECF con los

comprobantes que tú emites; el del Paso 3 trae ACEECF_Generadas con las facturas

que otra empresa te emitió y tú tienes que aprobar. La pantalla te dice cuál subiste y

cuál esperaba: llévalo al paso que le toca.

El Paso 3 (Aprobaciones Comerciales) no se sube al portal de la DGII.

Correcto, y es la parte que más confunde. En el Paso 2 firmas y subes; en el Paso 3

envías las aprobaciones al servicio de la DGII desde la plataforma, y el portal se

actualiza solo. Sube el archivo, revisa la lista y pulsa Enviar aprobaciones. Van una

por una a propósito: si alguna falla, ves cuál.

La DGII rechazó una aprobación por la fecha y hora, y ahora el set aparece vacío.

La hora de la aprobación no es la del envío: la DGII la fija en el archivo que te

entrega y la compara al segundo. La plataforma la reenvía tal cual, así que no la

modifiques al abrir el Excel. Y sí, cualquier rechazo reinicia el set completo —no

solo el comprobante rechazado—, así que hay que volver a enviarlo entero. Reenviar es

seguro: no se duplica nada.

Si el Set de Pruebas falla, ¿puedo volver a enviarlo con el mismo archivo?

Sí. El Excel del Set de Pruebas trae los e-NCF fijos y esos números no salen de tus

secuencias autorizadas, así que reenviar el mismo documento con el mismo e-NCF es lo

correcto. La plataforma reutiliza el registro del intento fallido y lo deja limpio antes

de reenviar. Corrige lo que reportó la DGII (datos del emisor, secuencias, XML) y vuelve

a pulsar Generar y Enviar con el mismo archivo.

Esto aplica sólo a documentos en estado Rechazado o Error, y sólo fuera de producción. Si el e-NCF corresponde a un documento aceptado o todavía en vuelo, la plataforma lo bloquea con un aviso: un e-CF aceptado no se reescribe, se corrige con una Nota de Crédito (tipo 34).

En producción es distinto: un rechazo puede gastar el número. No supongas que se
recupera. Cuando la DGII rechaza por el contenido del comprobante, su respuesta puede
venir con la secuencia ya consumida, y entonces ese e-NCF no se vuelve a usar: la
corrección sale con el número siguiente. Por eso la plataforma comprueba los datos que
la DGII exige antes de pedir el número, y te frena con un aviso en lugar de dejar
que el rechazo te cueste una secuencia.

El contador del botón "Generar y Enviar" no coincide con la suma de las hojas del Excel. ¿Está bien?

Sí. La hoja RFCE del Set describe los mismos documentos que las facturas de consumo menores a 250 000 de la hoja ECF — es su representación resumida, no documentos aparte. La plataforma los emite una sola vez: arma la factura completa, la firma, extrae el CodigoSeguridadeCF de esa firma y envía el RFCE. Por eso el botón cuenta los documentos de la hoja ECF.