¿Cómo factura electrónicamente un restaurante o soda?

Es que el comprobante fiscal de cada cuenta salga como un documento electrónico —el comprobante electrónico de la versión 4.4—, no como una factura de papel. En el servicio de comidas la mayoría de las cuentas son a consumidor final, así que lo normal es un tiquete electrónico (tipo 04): no hace falta pedirle la cédula al comensal.

Cuando el cliente sí quiere deducir el gasto —la cena de una empresa, un almuerzo de negocios— pide factura electrónica (tipo 01) con la cédula jurídica. Es el mismo flujo, solo cambia el tipo de comprobante y se agregan los datos del receptor. Esa distinción, en detalle, está en factura vs. tiquete electrónico.

Esta es la duda que más se repite en el sector. El 10 % de servicio (el «impuesto de servicio» que muchos restaurantes agregan a la cuenta) no es un producto y no se suma dentro del IVA. En la versión 4.4 va en un bloque aparte llamado «Otros Cargos», con su propio tipo, su porcentaje y su monto —así queda claro en el XML qué parte de la cuenta es servicio y no comida—.

Que el comprobante de tu restaurante o soda tiene que ser el XML de la versión 4.4, firmado con XAdES, con su clave numérica de 50 dígitos y aceptado por Hacienda. La 4.4 es obligatoria desde el 1 de setiembre de 2025 —las fechas y los cambios los seguimos en facturación electrónica 4.4—.

El servicio de comidas está gravado con el IVA general del 13 %. Cada plato o bebida se factura como una línea con su tarifa; el detalle de las tarifas (13 %, y las reducidas de 4 %, 2 %, 1 % para canasta básica, más lo exento) está en tarifas de IVA en Costa Rica. El 10 % de servicio se reporta como otro cargo del tipo «impuesto de servicio 10 %» (código 06) del catálogo de la 4.4.

Con una API REST. Al cerrar la mesa, tu punto de venta hace un POST a /api/procesar con las líneas de la comida y —si aplica— el 10 % de servicio en otros_cargos. La respuesta es HTTP 202: te devuelve la clave de 50 dígitos y el consecutivo en segundos, para que el tiquete imprima sin que la fila se frene. La firma y el envío a Hacienda corren en background.

const res = await fetch('https://api.plaxp.com/api/procesar', {
  method: 'POST',
  headers: { 'X-API-Key': process.env.PLAXP_API_KEY },
  body: JSON.stringify({
    tipo_documento: '04',        // 04 = tiquete (consumidor final) · 01 = factura
    codigo_sucursal: '001',
    codigo_caja: '001',
    condicion_venta: '01',       // 01 = contado
    medios_pago: [{ tipo: '02', monto: 6150 }],   // 02 = tarjeta
    lineas: [{
      codigo_cabys: '<cabys-del-plato>',
      detalle: 'Casado con pollo',
      cantidad: 1,
      precio_unitario: 5000,
      codigo_tarifa: '08',       // 08 = IVA 13%
      tarifa: 13,
    }],
    otros_cargos: [{
      tipo_documento: '06',      // 06 = impuesto de servicio 10%
      detalle: 'Servicio 10%',
      porcentaje: 10,
      monto_cargo: 500,          // 10% de la comida (₡5.000)
    }],
  }),
});
// ← 202: { clave, consecutivo } en segundos → imprimí el tiquete ya.

El tipo_documento: '06' del cargo es el que Hacienda espera para el impuesto de servicio; en el XML sale como <OtrosCargos> con su porcentaje y su monto, separado de las líneas y del IVA. No tocás XML ni librerías de firma: subís tu .p12 una vez y mandás JSON.

• El 10% de servicio va como «Otros Cargos» (tipo 06), no como plato ni dentro del IVA
• Un solo campo decide tiquete (consumidor final) o factura (con cédula)
• La clave vuelve en segundos (202): la caja imprime sin frenarse en hora pico
• El PDF y el XML le llegan al cliente por correo, como exige la norma
• El estado en Hacienda lo consultamos nosotros; tu sistema lo lee por clave

Un cliente pide un casado con pollo a ₡5.000 y paga con tarjeta. El sistema factura la comida con IVA del 13 % (₡650) y agrega el 10 % de servicio: ₡500 como otro cargo. La cuenta queda así:

Como es consumidor final, sale un tiquete electrónico (tipo 04) con su clave de 50 dígitos; el cliente sigue su camino sin esperar. Un rato después llega la mesa de una empresa que pide factura con la cédula jurídica: el cajero no cambia de sistema, emite una factura electrónica (tipo 01) con los datos del receptor y a esa empresa le llega el PDF y el XML a su correo.

Te damos credenciales de sandbox para probar el flujo completo —tiquete, factura y el 10 % de servicio— sin emitir en real, y te acompañamos en la integración con tu POS. Si venís de otra herramienta, mirá la comparativa de sistemas o cómo hacés el cambio en migrar de TicoFactura.