¿En qué te echamos la mano?

Ve a Emitir → Nuevo e-CF. Eliges el tipo (por ejemplo Factura de Crédito Fiscal 31), pones el cliente por RNC/cédula, agregas los ítems con su ITBIS y le das Emitir.

Bisnia arma el XML, lo firma con tu certificado, le asigna el e-NCF de la secuencia y lo envía a la DGII. En segundos ves el estado: aceptado, en proceso o rechazado.

Un POST a /v1/ecf con tu API key y el comprobante en JSON. Bisnia se encarga del XML, la firma y el envío a la DGII.

curl https://ecf.bisnia.com/v1/ecf \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "tipo": 31,
    "receptor": { "rnc": "101010101" },
    "items": [
      { "descripcion": "Consultoría", "cantidad": 1,
        "precio": 10000, "itbis": 18 }
    ]
  }'

La respuesta trae el eNCF, el estado y el track_id. El resultado final de la DGII te llega por webhook. Detalles en la referencia API.

Bisnia soporta los diez tipos definidos por la DGII. Se identifican por el código dentro del e-NCF:

• 31 — Factura de Crédito Fiscal
• 32 — Factura de Consumo
• 33 — Nota de Débito
• 34 — Nota de Crédito
• 41 — Compras
• 43 — Gastos Menores
• 44 — Regímenes Especiales
• 45 — Gubernamental
• 46 — Exportaciones
• 47 — Pagos al Exterior

Para consumo por debajo de RD$250,000 existe el RFCE (formato resumido). Bisnia lo aplica solo cuando corresponde.

La representación impresa es el PDF legible del e-CF que le entregas al cliente. Incluye el código QR que la DGII exige, con el que cualquiera valida el comprobante en el portal oficial.

Bisnia genera la RI automáticamente por cada e-CF aceptado. La descargas del panel o la obtienes por API en /v1/ecf/{eNCF}/ri (PDF).

El e-NCF es el número del comprobante (empieza con E + tipo + secuencia, ej. E310000000001). La DGII te autoriza rangos por tipo, y Bisnia consume el siguiente número disponible en cada emisión, sin saltos ni repetidos.

En Empresa → Secuencias ves cuántos e-NCF te quedan por tipo. Bisnia te avisa cuando una secuencia se está agotando para que solicites más a tiempo.

Un e-CF aceptado no se "borra": se corrige con otro comprobante. Para devoluciones o descuentos usas una Nota de Crédito (34); para cargos adicionales, una Nota de Débito (33), ambas referenciando el e-NCF original.

Las anulaciones de secuencia (números no usados) se reportan en el 608. Bisnia arma ese reporte por ti.

Cuando un proveedor te emite un e-CF, la DGII lo enruta a tu buzón de recepción. En Recepción → Entrada ves cada comprobante recibido con su e-NCF, emisor y monto.

También puedes recibirlos por API en tu endpoint de recepción, o consultarlos con GET /v1/recepcion.

El ARECF (Acuse de Recibo de e-CF) le confirma a la DGII y al emisor que recibiste el comprobante y que el XML es válido a nivel técnico. No dice si estás de acuerdo con la compra, solo que llegó bien.

Bisnia genera y envía el ARECF automáticamente por cada e-CF que recibes, dentro del plazo que exige la DGII. No tienes que hacer nada.

El ACECF (Aprobación Comercial de e-CF) es donde tú dices si estás de acuerdo con la operación: aceptar o rechazar la factura del proveedor por motivos comerciales (precio incorrecto, mercancía no recibida, etc.).

Desde Recepción → Entrada abres el comprobante y eliges Aprobar o Rechazar con un motivo. Por API es un POST /v1/recepcion/{eNCF}/aprobacion.

Los e-CF que recibes son tus compras, así que alimentan tu reporte 606. El 607 es de tus ventas (lo que emites). Bisnia clasifica cada comprobante en el reporte correcto y te arma 606, 607 y 608 listos para presentar.

Hay planes por volumen mensual de e-CF más una opción por uso para quien emite poco. Todos incluyen los 10 tipos, firma, recepción y reportes; la diferencia está en el volumen incluido y el soporte. Los precios en DOP con ITBIS visible están en bisnia.com/#precios.

Contamos e-CF emitidos y aceptados en producción durante el mes. El simulador y CerteCF no consumen cuota, así que prueba todo lo que quieras. En Facturación → Uso ves tu consumo en vivo y cuánto te queda del plan.

El pago es por transferencia bancaria a FISM Technology SRL (FISMRD.tech). En Facturación → Pagar generas la orden con el monto e ITBIS, y ahí mismo salen los datos de la cuenta y la referencia que debes poner en la transferencia.

1. Genera la orden en el panel.
2. Transfiere el monto exacto poniendo la referencia indicada.
3. Sube el comprobante de la transferencia (o escríbelo a pagos).

Cuando validamos la transferencia, tu plan queda activo y lo ves reflejado en Facturación con la fecha y el período cubierto. Si transferiste con la referencia correcta, la confirmación es rápida. ¿No aparece en 24h hábiles? Escríbenos a pagos@bisnia.com con el comprobante y lo resolvemos.

Claro. FISM Technology SRL te emite su propio e-CF (Factura de Crédito Fiscal) por el servicio, con su ITBIS, para que lo uses como gasto deducible. Te llega por correo y queda en tu recepción.

Casi siempre es el enrolamiento en la OFV (Oficina Virtual). Tener el certificado cargado en Bisnia no basta: tu certificado debe estar enrolado/asociado a tu RNC en la Oficina Virtual de la DGII para que acepte la autenticación.

Repasa esto:

• El certificado está vigente (no vencido ni revocado).
• El RNC del titular del certificado coincide con el RNC emisor.
• El certificado está enrolado en la OFV de la DGII para e-CF.

Un rechazo trae siempre un código y un mensaje de la DGII. Bisnia te lo muestra en claro en el detalle del comprobante. Las causas más comunes:

• RNC receptor inexistente o inactivo — verifica el RNC del cliente.
• e-NCF fuera de rango o duplicado — la secuencia no corresponde.
• Montos que no cuadran — el ITBIS o el total no coinciden con el detalle.
• Fechas inválidas — fecha de emisión fuera del rango permitido.

Corriges el dato señalado y vuelves a emitir. El comprobante rechazado no consume cuota.

El estado en proceso significa que la DGII recibió el comprobante pero aún no devuelve el resultado final. Es normal en picos de carga o mantenimientos de la DGII.

Bisnia reintenta la consulta automáticamente hasta obtener respuesta; no pierdes el comprobante ni tienes que reenviarlo. Cuando la DGII responde, el estado cambia solo y te llega el webhook.

Bisnia acepta tu emisión, la firma y la encola. En cuanto la DGII vuelve, envía los pendientes en orden y te actualiza los estados. Tú sigues facturando; nosotros nos encargamos de la reintentadera. Eso ta' resuelto.

La firma del e-CF usa el digest exacto que valida la DGII. Si ves un error de firma:

• Confirma que el certificado no venció a mitad de camino.
• Revisa que la contraseña del .p12 cargada siga siendo la correcta (si la cambiaste, vuelve a subirlo).
• Verifica que el certificado esté enrolado en la OFV.

El firmado lo maneja Bisnia; tú no armas XML a mano. Si el error persiste con todo en orden, es para soporte.

En el panel, Ajustes → API keys. Generas claves separadas para simulador y producción; cada una empieza con sk_test_ o sk_live_. Guarda la clave al momento: por seguridad no la volvemos a mostrar completa.

Se manda en el header Authorization: Bearer sk_live_.... Puedes revocar y rotar claves cuando quieras sin afectar tus e-CF ya emitidos.

En Ajustes → Webhooks registras tu URL https. Bisnia te avisa cuando cambia el estado de un e-CF (ecf.aceptado, ecf.rechazado) y cuando recibes uno nuevo (recepcion.nuevo).

Cada evento viene firmado con una cabecera X-Bisnia-Signature para que verifiques que es legítimo. Si tu endpoint falla, reintentamos con backoff.

// verifica la firma del webhook
const ok = verifyHmac(
  req.rawBody,
  req.headers['x-bisnia-signature'],
  process.env.BISNIA_WEBHOOK_SECRET
);

SDKs oficiales para Python, TypeScript/JavaScript, Go y PHP. Envuelven la API REST, manejan auth y tipan las respuestas.

# Python
from bisnia import Bisnia
b = Bisnia(api_key="sk_live_...")
ecf = b.ecf.crear(tipo=31, receptor={"rnc":"101010101"}, items=[...])
print(ecf.encf, ecf.estado)

Instalación y ejemplos por lenguaje en la documentación.

El MCP (Model Context Protocol) deja que un agente de IA (como Claude) emita, consulte y reciba e-CF hablando con Bisnia de forma nativa. Conectas el servidor MCP con tu API key y tu asistente puede facturar por ti.

Es facturación AI-native: "emítele una factura de RD$5,000 a este RNC" y el agente lo hace. Configuración en la documentación.

La referencia OpenAPI interactiva vive en ecf.bisnia.com/v1/docs: todos los endpoints, esquemas y códigos de error, con "probar" en vivo. La guía de conceptos está en bisnia.com/docs.

Sí, para proteger el servicio. Los límites vienen en las cabeceras X-RateLimit-Remaining y X-RateLimit-Reset de cada respuesta. Si te pasas, recibes 429 y basta con reintentar tras el reset. Para volúmenes altos, escríbenos y ajustamos tu cupo.