Facturación electrónica para tu ERP en Costa Rica

Significa que el ERP declara la venta y un servicio aparte la convierte en un comprobante fiscal válido. Son dos responsabilidades distintas: tu ERP sabe qué se vendió, a quién y por cuánto; la capa fiscal sabe cómo convertir eso en el comprobante electrónico que Hacienda exige —con su clave de 50 dígitos, su consecutivo de 20 y su firma.

Conectarlas por API hace que sean el mismo flujo: cuando el ERP cierra la factura de venta, la orden de despacho o el asiento, dispara la emisión sin que nadie reteclee nada. Es la contracara de facturar en un portal aparte —el problema de la doble digitación.

Porque no es una feature que se hace una vez: es mantenimiento permanente. Meter dentro del ERP el generador de XML, la firma XAdES, la custodia del .p12, los consecutivos sin huecos y el polling contra Hacienda parece factible el primer mes —y se vuelve una deuda que hay que actualizar cada vez que Hacienda mueve el esquema. La pregunta de fondo es construir vs. usar un motor:

• Tu equipo mantiene el ERP; la burocracia de Hacienda la lleva el motor
• Cero código de firma XAdES ni parsers de XML dentro de tu producto
• Menos superficie de rechazos por totales o CABYS mal armados
• Los cambios de versión de Hacienda no te obligan a releasar el ERP
• El certificado .p12 no vive esparcido en tu base de código

Para Hacienda el resultado tiene que ser el mismo XML de la versión 4.4, firmado con XAdES, con su clave de 50 dígitos y su consecutivo, y aceptado para tener validez fiscal —lo emita un ERP, un POS o un portal. Pero la 4.4 es justamente lo que hace peligroso construir la capa adentro: es un blanco móvil.

• La 4.4 es obligatoria desde el 1 de setiembre de 2025
• El código de referencia 03 quedó eliminado en la 4.4
• Entra el nuevo catálogo CABYS (vigente jun-2026)
• Los anexos 4.4 pasan a ser obligatorios el 1 de noviembre de 2026
• Aparece el REP (recibo electrónico de pago) como comprobante nuevo

Cada uno de esos cambios, si vive dentro de tu ERP, es una tarea de tu equipo. Si vive en el motor, tu ERP no se entera. Seguimos las fechas y los cambios en facturación electrónica 4.4: qué cambia y desde cuándo.

Con una API REST. Tu ERP hace un POST a /api/procesar con los datos de la venta y nosotros nos ocupamos del resto: generamos el XML v4.4, lo firmamos con XAdES, lo enviamos a Hacienda y le mandamos al receptor el PDF y el XML por correo. La respuesta es HTTP 202: recibís la clave al instante y la firma y el envío corren en background.

// tu ERP ya tiene la venta armada; solo la declara:
await fetch('https://api.plaxp.com/api/procesar', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-API-Key': process.env.PLAXP_API_KEY,   // la del emisor de esa empresa
  },
  body: JSON.stringify({
    tipo_documento: '01',          // 01=FE · 04=Tiquete · 03=NC · 02=ND
    codigo_sucursal: '001',
    codigo_caja: '001',
    consecutivo: factura.numero,
    condicion_venta: '01',
    medios_pago: [{ tipo: '01', monto: factura.total }],
    receptor: { /* del cliente del ERP */ },
    lineas: factura.lineas,        // con su codigo_cabys por producto
  }),
});
// ← 202: clave de 50 dígitos al instante. El estado final se lee por clave.

No tenés que implementar polling contra Hacienda ni recibir webhooks: Plaxp consulta el estado por vos (con reintentos y backoff) y tu ERP lo lee por clave con GET /api/consultar/:clave. El detalle está en estado del comprobante y el catálogo de rechazos en errores de Hacienda v4.4.

Es el caso típico de un ERP: varias empresas, cada una con su cédula, su certificado y su secuencia. En Plaxp cada empresa es un emisor con su propia API Key. Tu ERP provisiona un emisor por cliente y, al emitir, usa la llave de ese emisor —así los consecutivos, los certificados y el correo del receptor nunca se cruzan entre empresas.

Una distribuidora factura desde su ERP unas 300 facturas al día entre su bodega central y dos sucursales. Antes exportaban a un portal y alguien retecleaba las que no cuadraban: horas perdidas y rechazos por totales inconsistentes.

Ahora, cuando el ERP cierra una factura de ₡120.000, hace un solo POST: Plaxp arma el XML, aplica el IVA del 13 % (₡13.805,31 sobre la base para un total de ₡120.000), genera la clave, firma y envía a Hacienda en segundos. El ERP guarda la clave contra su factura y sigue con lo suyo —inventario y contabilidad se mueven en el mismo flujo, sin una capa fiscal que mantener adentro.

Por la documentación de la API: ahí están los tipos de comprobante, la autenticación y los ejemplos en varios lenguajes. Te damos credenciales de sandbox (TRIBU-CR) para probar el flujo completo sin emitir en real. Si tu ERP hoy exporta a otra herramienta, mirá la comparativa de sistemas o en migrar de TicoFactura. Y si desarrollás sistemas para terceros, mirá proveedor de comprobantes electrónicos para sistemas.