Inbox de comprobantes

Bandeja de e-CF entrantes: cómo decidir Aceptar / Rechazar / Aceptación Parcial sobre los comprobantes que tus proveedores te emiten.

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.
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.

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.
Los miembros con rol OWNER del tenant tienen ambos 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

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.
Trazabilidad completa frente a DGII en una auditoría posterior.

Relacionados

Última actualización: 2026-05-03

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.

Inbox de comprobantes

En esta página