Panamá tiene uno de los sectores de restauración más densos de Centroamérica: desde fondas de barrio hasta cadenas de comida rápida, restaurantes de alta cocina en Casco Viejo, food courts en MultiPlaza, plazas de comida en provincias y operaciones nocturnas en Calle Uruguay. Cada formato tiene su propia operación, pero todos comparten una característica: la herramienta correcta no es un sistema contable adaptado, es un ERP nacido para restaurante con POS integrado.
El error más común en el sector es ver el POS y la contabilidad como dos mundos separados. Resultado: ventas que el contador re-digita al sistema contable, inventario que se cuenta físicamente cada mes porque el sistema no lo descuenta automáticamente, mermas que nadie cuantifica, y propinas en una hoja de Excel aparte. Ese modelo no escala.
Por qué un restaurante necesita un ERP especializado
Las cinco realidades que un sistema genérico no maneja bien:
- Recetas (BOM): el plato "corvina al ajillo" consume 200g de corvina, 30ml de aceite, ajo, vino blanco, perejil. Cada vez que se vende, debe descontarse del inventario en esas cantidades.
- Multi-estación: caja, mesero con tablet, kitchen display, comandero. Todo debe sincronizar en tiempo real.
- Propinas: tienen tratamiento legal y CSS específico en Panamá; no son ingreso del restaurante sino del trabajador.
- Delivery aggregators: el pedido entra por canal externo, paga comisión, y necesita conciliarse contra el reporte semanal/mensual del aggregator.
- ITBMS de servicios de restaurante: aplica al 10% en alimentos consumidos en el local en ciertos casos (revisar resolución vigente).
Los 11 requisitos clave
1. POS integrado al ERP, no separado
El POS y el back-office deben ser el mismo producto, no una integración entre dos sistemas. Cada venta debe descontar inventario al instante y generar el asiento contable sin intervención.
2. Recetas (BOM de plato)
Cada item del menú debe tener su receta con cantidades exactas de ingredientes. Cuando se vende el plato, el sistema descuenta automáticamente. Sin esto, el costo de comida es una estimación, no un dato.
3. Costo de plato y costo de comida (food cost)
El reporte clásico: costo unitario del plato vs precio de venta, margen bruto, food cost porcentaje. Permite identificar platos que erosionan el margen y ajustar menú o precio.
4. Multi-tienda con consolidación
Cadenas con varias sucursales necesitan operación independiente por tienda (ventas, inventario, planilla) y consolidación financiera al cierre. Transferencias entre tiendas (pollo de bodega central a sucursal) deben ser automáticas.
5. Manejo de propinas (propina por servicio)
La propina es del mesero (o se distribuye según política interna). El ERP debe registrar la propina aparte del precio del plato, mantenerla como cuenta por pagar al personal, distribuirla según fórmula configurada y reportarla al CSS cuando aplica.
6. Comandas y kitchen display (KDS)
El pedido debe llegar a cocina sin papel: pantalla en parrilla, fría, postres. Cada estación marca cuando termina el item, el mesero ve el estado en la tablet, y el cliente recibe la comida sincronizada.
7. Mesas, comanderos y mozos
Mapa de mesas, asignación de mesero por zona, división de cuenta entre comensales, fusión y separación de cuentas, transferencia de mesa, todo desde la tablet del mesero. Sin pasar por la caja para cada acción.
8. Integración con delivery aggregators
PedidosYa, Uber Eats, Rappi, DiDi Food. El ERP debe recibir el pedido directo del aggregator, mostrarlo en cocina como una orden más, registrar la venta con el canal correcto, descontar inventario, y conciliar contra el corte semanal/mensual del aggregator (ventas brutas, comisiones, retenciones).
9. Cumplimiento DGI y ITBMS de restaurantes
Facturación electrónica con CUFE para todas las ventas (incluida la de delivery), CUFE generado al instante por el POS, ITBMS calculado correctamente (10% en alimentos consumidos en el local en ciertos supuestos, 7% en otros), reporte mensual a DGI sin retrabajo.
10. Planilla por hora con turnos rotativos
El personal de salón y cocina suele estar por hora con turnos variables. El ERP debe manejar marcaje, cálculo de horas extras, distribución de propinas, integración a SIPE y al banco para depósito.
11. Reportes operativos en tiempo real
Ventas por hora del día, ventas por mesero, ventas por canal (mesa / barra / delivery / takeaway), top 10 platos, costo de comida vs presupuesto, mermas, descuentos otorgados, comparación contra mismo día semana anterior. Si el dueño no ve esto desde el celular, el ERP no está cumpliendo.
ITBMS de restaurantes en Panamá
Los servicios de restaurante en Panamá tienen tratamiento ITBMS específico. La regla general - sujeta a verificación con la resolución vigente y tu asesor fiscal - es:
- Alimentos consumidos en el local con servicio: tarifa que puede llegar al 10% en establecimientos formales con servicio de mesa.
- Take-away y delivery: generalmente 7% (la tarifa estándar de ITBMS).
- Bebidas alcohólicas: tarifa diferenciada según tipo y empaque.
El ERP debe poder configurar tarifas distintas por tipo de venta (mesa vs delivery vs barra) y aplicarlas automáticamente al CUFE.
Manejo de propinas: lo que más equivocan los sistemas genéricos
En Panamá, la propina sugerida en restaurantes formales suele ser de 10% sobre el subtotal y muchos restaurantes la incluyen en la cuenta. Lo correcto es:
- La propina no es ingreso del restaurante; es un pago al personal.
- Debe registrarse como cuenta por pagar al fondo de propinas.
- La distribución se hace según la política interna (por mesero, por turno, repartido entre meseros y cocina, etc.).
- Cuando se paga al trabajador, hay tratamiento CSS específico (consultar la regla vigente).
Sistemas genéricos suelen sumar la propina al ingreso, lo que sobreestima ventas y crea problemas de impuesto sobre la renta y de obligación con el personal.
Multi-tienda: cadenas de restaurantes
Una cadena de 5 restaurantes en Panamá necesita:
- Bodega central que suministra a las sucursales con transferencias documentadas.
- Inventario separado por tienda con conteos independientes.
- Recetas centralizadas (mismo plato cuesta lo mismo cocinarlo en cualquier tienda).
- Reportes consolidados (ventas totales, costo total, margen) y por sucursal.
- Planilla por tienda con marcaje y propinas locales.
- Una sola facturación electrónica DGI con multi-empresa o multi-sucursal.
Mas detalle en nuestra guia de consolidación multi-empresa NIIF.
Costos típicos de implementación
| Tamaño operación | Suscripción | Implementación inicial | Plazo |
|---|---|---|---|
| Restaurante único (1 tienda, 1-2 cajas) | B/.250 - B/.550 mensuales | B/.4,000 - B/.10,000 | 1 - 2 meses |
| Cadena pequeña (2-5 tiendas) | B/.700 - B/.1,800 mensuales | B/.10,000 - B/.28,000 | 2 - 3 meses |
| Cadena mediana o franquicia (6-20 tiendas) | B/.1,800 - B/.5,000 mensuales | B/.28,000 - B/.75,000 | 3 - 5 meses |
Errores comunes en restaurantes con sistema genérico
- Sin recetas: el costo del plato es opinión del chef, no dato del sistema.
- Inventario solo mensual: el conteo físico al fin de mes revela B/.5,000 de mermas que nadie puede explicar.
- Propina como ingreso: infla ventas, sube ITBMS y genera reclamo del personal.
- Delivery sin reconciliar: aggregator paga 30 días después con comisiones, retenciones y propinas mezcladas; sin reporte automatizado, no se sabe si el aggregator está pagando lo correcto.
- POS en isla: caja en una computadora, contabilidad en otra; cada cierre es 4 horas de cuadre manual.