Inbox de comprobantes

Bandeja de e-CF entrantes: cómo decidir Aceptar / Rechazar / Aceptación Parcial sobre los comprobantes que tus proveedores te emiten, y cómo se entrega esa decisión al sistema del emisor.

El Inbox de comprobantes es donde aparecen los e-CF que tus proveedores emiten a tu nombre. Cuando un emisor electrónico te factura, DGII rutea ese XML hasta una URL pública que Mosce ERP expone, lo persiste, devuelve un acuse firmado (ARECF) y lo deja listo para que tomes la decisión comercial: Aceptar, Rechazar o Aceptación Parcial. Esa decisión se firma en un ACECF y se envía a DGII; una vez enviada, no se revierte desde Mosce ERP.

Tiempo de lectura: ~7 min

Cuándo usar esto

Recibiste un e-CF de un proveedor y necesitás decidir si lo aceptás o no.
Querés ver el histórico de comprobantes que entraron a tu nombre y el estado de cada decisión comercial.
Tu contador pregunta cuándo llegó un e-CF específico de un proveedor.
Recibiste un e-CF que no es para vos (RNC equivocado) y querés entender qué hacer.
Querés entender la diferencia entre el acuse técnico (ARECF) y la decisión comercial (ACECF).

Antes de empezar

El módulo Fiscal está activo y tu rol incluye fiscal:read (para ver el inbox) o fiscal:inbound:decide (para tomar decisiones). Los OWNER del tenant tienen ambos permisos implícitamente.
Mosce ERP está registrado como receptor electrónico ante DGII y las URLs públicas del tenant están dadas de alta en la Oficina Virtual del contribuyente. Ver URLs DGII y portal de certificación.
Hay e-CF entrantes para revisar. La bandeja parte vacía hasta que llega el primero.

Cómo llegan los e-CF a Mosce ERP

Cuando un emisor te factura, su sistema (Mosce ERP u otro) envía el XML firmado a la URL pública de recepción que tu RNC tiene registrada en DGII (ver URLs DGII portal). Mosce ERP:

Recibe el XML en formato multipart/form-data.
Identifica a tu organización por el <RNCComprador> del XML - la misma URL pública sirve a múltiples organizaciones y el routing lo decide el RNC dentro del documento.
Verifica la firma digital con el certificado público del emisor.
Valida el XML contra el XSD canónico DGII del tipo correspondiente.
Persiste el comprobante en su almacenamiento interno.
Construye y firma un Acuse de Recibo (ARECF) con el certificado de tu organización.
Devuelve el ARECF en la respuesta HTTP (síncrono, dentro de los 10 segundos).
Actualiza el Inbox en tiempo real para que veas el nuevo comprobante sin tener que recargar.

El ARECF es técnico: confirma que recibiste el comprobante y que pasó las validaciones de firma y schema. No es una aceptación comercial - esa decisión la tomás vos en el inbox.

La tabla del Inbox

Disponibilidad. La pantalla del Inbox y los diálogos de decisión ya están en la UI. El listado se rellena con los comprobantes recibidos a medida que la integración inbound queda completamente activa; si abrís el Inbox y aparece vacío aunque sabés que recibiste un e-CF, contactá a soporte para verificar el routing de tu RNC.

Abre Fiscal → Inbox desde el menú lateral. La pantalla requiere que el módulo Fiscal esté habilitado para tu organización y que tu rol incluya el permiso fiscal:inbound:decide (o que seas OWNER). Si falta cualquiera, ves una pantalla de permiso denegado con un botón para volver a Fiscal.

La tabla muestra una fila por comprobante recibido con las siguientes columnas:

Columna	Contenido
Sender	RNC del emisor + razón social (si la sabemos por el directorio DGII; si no, "Emisor desconocido").
e-CF	Número del comprobante, 13 caracteres (ej. `E310000123456`).
Recibido	Fecha y hora en que la URL `/fe/recepcion/api/ecf` recibió el XML.
Aprobación	Badge con el estado de la decisión comercial: Pendiente, Aceptado, Rechazado o Aceptación Parcial.
Decidido	Fecha y hora en que se envió la decisión a DGII. Vacío mientras esté Pendiente.
Entrega	Badge con el estado de entrega de tu decisión al sistema del emisor: En proceso, Entregada o No entregada. Sin valor (`-`) mientras la decisión todavía no se evaluó para entrega. Ver La entrega de tu decisión al sistema del emisor.
Acciones	Botones Aceptar, Aceptación Parcial y Rechazar - solo visibles para filas en estado Pendiente y solo si tenés `fiscal:inbound:decide`.

La decisión comercial - Aceptar, Rechazar o Aceptación Parcial

Cuando recibís un e-CF de un proveedor, DGII espera que tomes una decisión comercial sobre la operación que el comprobante respalda. Esa decisión se materializa en un XML llamado ACECF (Acuse Comercial e-CF) que Mosce ERP firma con tu certificado y POSTea a DGII. La decisión queda registrada en DGII y replicada en Mosce ERP; el resumen del estado de aprobación comercial del comprobante refleja la decisión más reciente.

Cuándo elegir cada una

Decisión	Cuándo elegirla	Efecto
Aceptar	La operación es correcta - recibiste lo facturado, el monto y los impuestos cuadran, vas a usar el comprobante para sustentar costo, gasto o crédito fiscal.	ACECF firmado con `<Estado>` aceptado se envía a DGII. El estado de aprobación queda en Aceptado.
Aceptación Parcial	Recibiste parte de lo facturado o hay diferencias pero querés aceptar lo que sí corresponde. La razón es opcional pero recomendada.	ACECF firmado con `<Estado>` parcial se envía a DGII. El estado queda en Aceptación Parcial.
Rechazar	El comprobante es incorrecto, no recibiste el bien/servicio, hay error en datos, montos o impuestos. La razón es obligatoria.	ACECF firmado con `<Estado>` rechazado se envía a DGII. El estado queda en Rechazado.

Flujo de UI

Aceptar - confirma con window.confirm (sin diálogo modal pesado) y dispara el POST de inmediato. La fila se actualiza en cuanto llega el OK.
Aceptación Parcial - abre un diálogo con un campo Razón opcional (hasta 500 caracteres). Confirmás con Aceptación Parcial y la decisión se envía firmada.
Rechazar - abre el mismo diálogo pero con la razón obligatoria. Si dejás el campo vacío, el botón de confirmar muestra un toast con el mensaje "Razón requerida" y la decisión no se envía.

Al confirmar cualquiera de las tres, Mosce ERP:

Construye el ACECF con tu razón (si la hay), el RNC del emisor, el e-CF original y el <Estado> correspondiente.
Lo firma con el certificado de tu organización (plataforma o propio).
Persiste la decisión con una llave única que garantiza idempotencia natural: una decisión ya enviada no se puede duplicar.
Lo envía a DGII de manera asincrónica para no bloquear la UI.
Actualiza el resumen de aprobación comercial del comprobante para reflejar la decisión más reciente.

Idempotencia y por qué la decisión no se revierte desde Mosce ERP

La unicidad de la decisión por comprobante es deliberada. Una vez que la decisión se envió a DGII, no se puede sobrescribir desde Mosce ERP. Si intentás decidir un comprobante que ya tiene una decisión enviada, la UI rechaza la acción con un mensaje claro y no permite re-abrir el diálogo.

Este comportamiento es regulatorio, no de producto: DGII trata el ACECF como una declaración firmada del receptor. Reversarlo requiere que la operación se cancele en otro circuito (típicamente el emisor emite una Nota de Crédito - E34 - para revertir la operación, y vos la procesás en su turno como otro inbound). No es algo que un botón en Mosce ERP pueda deshacer porque la decisión ya está en DGII.

Si pensás que pulsaste el botón equivocado, contactá inmediatamente al emisor para coordinar la corrección por la vía contable correspondiente.

La entrega de tu decisión al sistema del emisor

Que la entrega falle no pone en duda tu decisión. Tu ACECF ya fue aceptado por la DGII y es válido apenas se envía. Que el servidor del proveedor no responda es un problema de su infraestructura, no de tu aprobación ni de tu rechazo.

El modelo de comprobación electrónica no termina con el envío del ACECF a la DGII: también espera que le hagas llegar esa misma decisión, firmada, directamente al sistema del proveedor que te emitió el e-CF. Mosce ERP lo hace automáticamente apenas la DGII acepta tu ACECF.

A diferencia del e-CF que vos recibís, acá no hay caso de "no aplica": si te llegó un e-CF para aprobar es porque quien te lo emitió es, por definición, un emisor electrónico, así que esta entrega siempre corresponde. La columna Entrega de la tabla muestra:

Estado	Qué significa
En proceso	La DGII ya aceptó tu decisión y Mosce ERP está intentando entregarla al sistema del proveedor, con reintentos automáticos.
Entregada	La decisión llegó al sistema del proveedor. Al pasar el cursor por el badge ves la fecha y hora.
No entregada	Se agotaron los reintentos automáticos sin que el sistema del proveedor respondiera, o el proveedor rechazó la entrega por un motivo que no se resuelve reintentando. Al pasar el cursor ves cuál de los dos casos es.

Igual que con la entrega de un e-CF que vos emitís (ver Documentos e-CF), los reintentos siguen una escalera de esperas crecientes durante 24 horas, hasta un total de 8 intentos. Si ninguno tiene éxito, el estado queda en No entregada. La mayoría de las veces esto significa que el sistema del proveedor no respondió a tiempo, y ahí sí te sirve reintentar: si tenés fiscal:manage, aparece el botón Reintentar entrega en la columna de Acciones - independiente de los botones de decisión, porque tu ACECF ya está aceptado y esto solo reinicia el intento de hacérselo llegar al proveedor. En un grupo más chico de casos el motivo no se resuelve reintentando (por ejemplo, que el proveedor rechazó la entrega o exige una autenticación que Mosce ERP todavía no soporta para terceros) - ahí el botón no aparece, porque volver a intentarlo no va a cambiar el resultado, y lo que corresponde es contactar directamente al proveedor.

Permisos y auditoría

fiscal:read - necesario para ver la pantalla del inbox y la tabla de comprobantes.
fiscal:inbound:decide - necesario para los botones Aceptar, Aceptación Parcial y Rechazar. Sin él, la pantalla muestra el listado pero las acciones están ocultas.
fiscal:manage - necesario para el botón Reintentar entrega de la columna Entrega. Es un permiso distinto de fiscal:inbound:decide: podés decidir sobre un comprobante sin poder reintentar su entrega, y viceversa.
Los miembros con rol OWNER del tenant tienen los tres permisos implícitamente - no necesitan asignación explícita.

Cada decisión queda registrada con su timestamp y se conserva el ACECF firmado en almacenamiento privado para auditorías DGII posteriores. La razón ingresada para Rechazo o Aceptación Parcial se persiste textualmente - escribí algo accionable, no "error". Esa razón puede aparecer en respuestas DGII y en disputas comerciales.

Errores comunes

Síntoma	Causa probable	Solución
Recibí un e-CF que no es para mí	El emisor escribió un RNC equivocado en el XML	Rechazá el comprobante con razón clara ("RNC receptor no corresponde a esta entidad"); el emisor debe emitir Nota de Crédito y reemitir
El sender RNC no aparece con razón social	El emisor todavía no fue indexado en la sincronización del directorio DGII	El nombre aparece como "Emisor desconocido" hasta que la entrada del directorio se sincronice
Los botones de decisión están deshabilitados aunque la fila está Pendiente	Te falta el permiso `fiscal:inbound:decide`	Pedí al administrador del tenant que actualice tus permisos o tu rol
Pulsé Aceptar y quiero deshacerlo	La decisión ya viajó a DGII y no es reversible desde Mosce ERP	Contactá al emisor; si la operación debe revertirse, el emisor debe emitir Nota de Crédito (E34) que vos procesás luego como otro inbound
El inbox está vacío aunque sé que un proveedor me facturó	La URL pública de tu tenant no está bien dada de alta en DGII OFV, o el emisor envió a una URL distinta	Revisá URLs DGII y portal de certificación y confirmá la URL registrada con tu emisor
Aparece Aceptación Parcial pero no recuerdo qué decidí	Inspeccioná la columna Decidido y abrí el detalle del comprobante para ver la razón guardada	La razón persistida es la que se mandó a DGII en el ACECF; consultala como evidencia de la decisión
La columna Entrega muestra No entregada	El sistema del proveedor no respondió durante la ventana de reintentos automáticos (24 h), o rechazó la entrega por un motivo que no se resuelve reintentando	Tu decisión ya es válida ante la DGII. Si el detalle ofrece Reintentar entrega, pulsalo cuando el proveedor esté disponible; si no lo ofrece, contactá directamente al proveedor

Resultado esperado

Lista en tiempo real de los e-CF que tus proveedores te emiten.
Cada comprobante con un estado claro de aprobación comercial.
Decisiones tomadas con auditoría completa: quién decidió, cuándo, con qué razón.
ACECF firmado y persistido por cada decisión enviada, idempotente por comprobante.
La decisión entregada al sistema del proveedor, con reintento automático y manual.
Trazabilidad completa frente a DGII en una auditoría posterior.

Relacionados

URLs DGII y portal de certificación
Documentos e-CF - la entrega electrónica en la otra dirección, de tus propios e-CF hacia el receptor.
Configuración fiscal
Certificado e-CF
Contingencia y planes de respaldo

Última actualización: 2026-09-16

Fuentes regulatorias

DGII - Formato Aprobación Comercial (ACECF): define la estructura del Acuse Comercial Electrónico, incluido el campo <Estado> con sus tres valores admitidos (aceptado, rechazado, aceptación parcial). Disponible en el portal DGII.
Decreto 587-24 y Norma General 01-2020: sustento regulatorio de la obligación de emitir ACECF, la naturaleza irreversible de la decisión y la trazabilidad fiscal del comprobante recibido.
DGII - Informe Técnico e-CF v1.0 §8 (página 15): en el modelo de operación, la entrega de la Aprobación o Rechazo Comercial al emisor electrónico es el paso 5; notificar a la DGII de esa respuesta es el paso 6. Disponible en el portal DGII.

Inbox de comprobantes

En esta página