Construye tu sistema de facturación y finanzas con Puente OS

0. Qué vas a construir

El problema. El cierre de mes se hace a mano:

• Cada factura recurrente se arma desde una planilla.
• Una factura sale dos veces, otra se olvida y un cobro indexado usa el valor de otro día.
• Para saber quién pagó, alguien cruza la cartola del banco con las facturas, línea por línea.
• Presupuesto y contabilidad se rehacen aparte.

El resultado. Una herramienta propia que calcula qué facturar, emite sin duplicar a través de tu proveedor de facturación electrónica, dice qué factura quedó pagada y proyecta la caja.

El mapa.

En cada flecha, una pieza escribe en una tabla y la siguiente la lee.

1. Los bloques de Puente OS que vas a usar

Apps. La pantalla de tu equipo: una aplicación web con link propio y una pestaña por tarea. Su key viaja con el código publicado, así que le das solo los permisos que usa.

Tablas. La memoria. Cada columna es texto, número, fecha, sí/no o lista de opciones, y la plataforma valida cada fila antes de guardarla.

Workflows. El brazo en el servidor: pasos encadenados que arrancan cuando la app llama a su webhook, a una hora fija o a mano. Aquí viven los secretos y las llamadas a sistemas externos.

Integraciones. Enchufes a otros sistemas dentro de un workflow: Gmail, Google Sheets, WhatsApp, e-commerce y un paso HTTP para el resto. Así habla la herramienta con tu proveedor de facturación electrónica (en Chile, por ejemplo Bsale, Wasabil o Nubox) y con tu software contable o de gestión (Chipax, Defontana u otro).

Agentes. Un modelo de lenguaje dentro de un workflow que redacta, clasifica o elige entre opciones cerradas. Billing OS corre con reglas explícitas y auditables, y sumas un agente donde el caso pide criterio.

2. Antes de construir, levanta tu proceso

Cada respuesta fija una perilla de la sección 5.

1. ¿En qué país facturas y qué documentos emites? → Autoridad y tipo de documento (tabla en 3.3).
2. ¿Qué proveedor de facturación electrónica usas, y tiene API? → Workflows de emisión.
3. ¿Qué impuestos aplican? → Tasas en config.
4. ¿Cobras en moneda local, en un índice o en divisa? → Tabla indices.
5. ¿Cobras cuota fija, consumo o hito, y cada cuánto? → Periodicidad de cada línea.
6. ¿Tus clientes exigen referencias en la factura? → OC, HES u otras.
7. ¿Qué fecha lleva el documento? → Valor del índice que se congela.
8. ¿Cómo bajas los movimientos del banco? → Importador de cartolas.
9. ¿Qué plan de cuentas usa tu contador? → Catálogo de categorías.
10. ¿Qué plazos de pago das? → Días de pago y tramos de antigüedad.
11. ¿Quién aprueba emitir y cuándo cierras? → Confirmaciones y estados del ciclo.
12. ¿Quién ve qué? → Permisos y apps separadas para datos sensibles.

Por dónde empezar. Elige el módulo que más duele, medido en horas y errores, y que menos depende de otros:

• Clientes y líneas (Paso 2): solo necesita las tablas del Paso 1.
• Ciclo (Paso 3): clientes y líneas.
• Borradores, emisión y panel (Pasos 4 y 5): ciclo y proveedor.
• Flujo de caja (Paso 6): cartola y clientes.
• Pagos y por cobrar (Paso 7): banco y facturas emitidas.
• Contabilidad y presupuesto (Pasos 8 y 9): casi todo lo anterior.

Si duele facturar, parte por clientes y líneas; si duele cobrar, por el flujo de caja. La primera versión lleva reglas básicas y un solo tipo de documento.

Paso 1 · Tus tablas

Qué resuelve. Todas las vistas leen de aquí, y un buen modelo evita duplicados y cruces fallidos.

Sin tipo indicado, la columna es texto. tax_id guarda el identificador tributario del receptor: RUT, RUC o RFC según el país.

Reglas de tipos.

• Identificadores como texto: traen letras y ceros a la izquierda.
• Fechas en AAAA-MM-DD; el período AAAA-MM, como texto validado.
• Cambiar las opciones de una lista exige migrar la estructura, así que un catálogo que cambia seguido va en config.
• Actualizar reemplaza la fila entera, y el cifrado de columnas sensibles se decide al crear la tabla.

Relaciones por convención. Cada relación es un campo común que la app compara: tax_id = cliente_tax_id, idem_key entre líneas y cargos, y contraparte_tax_id y folios_pagados desde el banco.

Por qué se diseñó así.

1. Identificador normalizado al escribir: tax_id sin puntos ni guion y en mayúsculas, igual en todos los cruces.
2. Llave anti-duplicado derivada del contenido (receta en el Paso 3): sobrevive aunque la fila se recree, y se busca en el proveedor antes de crear (Paso 4).
3. Foto del momento: el cargo copia razón social, glosa, montos e índice, y la factura queda congelada.
4. Baja lógica: clientes y líneas se desactivan y conservan su historial.

Estados. Una línea está activa, pausada o terminada, y solo la activa factura. El ciclo pasa por preparado, borradores, emitiendo y cerrado, o termina abortado. Los del cargo están en el Paso 4.

Cómo lo adaptas. Suma las columnas que exige tu documento: giro en Chile; régimen fiscal y código postal en México.

Cómo verificas que quedó bien. Crea a Cliente Demo Ltda. escribiendo su RUT ficticio con puntos y guion: debe guardarse sin ellos. Crea una línea con ese RUT y confirma que se asocia al receptor. Una unidad fuera de la lista debe rechazarse.

Paso 2 · Clientes y líneas de precio

Qué resuelve. Define a quién le facturas y qué le cobras cada mes. Con datos tributarios exactos y líneas con vigencia, el ciclo factura solo.

Qué construyes.

• clientes y lineas_facturables (Paso 1). Al receptor súmale actividad, dirección y email; a la línea, periodicidad, OC/HES y marca de exenta.
• Vistas «Clientes» y «Líneas y precios», más dos workflows: uno consulta el registro tributario y otro busca el receptor en el proveedor y lo crea si falta.

Cómo funciona.

• Receptor y cuenta comercial van por separado: varias cuentas y líneas pueden compartir receptor.
• Precio append-only: para cambiarlo cierras la línea vigente y creas otra, así el historial queda completo.
• Unidad: moneda local, índice (UF en Chile, UDI en México) o dólar. Periodicidad: mensual o puntual (una vez, en su mes de inicio); ofrece solo las que tu cálculo implementa.
• OC/HES: referencias que el comprador exige ver para aprobar el pago. Exenta: impuesto cero.
• El botón «Traer del registro» completa razón social y dirección, y el giro solo si estaba vacío.

Ejemplo ficticio. Cliente Demo Ltda. tiene dos cuentas comerciales. «Demo Retail» paga «Plan Operación», 12 UF mensuales, con la OC 4500-001. «Demo Online» paga «Implementación», $800.000, puntual en marzo.

Por qué se diseñó así.

1. El receptor va separado de la cuenta porque un mismo identificador paga servicios de varias áreas, cada uno con su precio y su OC.
2. Se respeta el giro cargado porque el giro principal ante la autoridad a veces difiere del que se usa para facturar.
3. Se busca el receptor en el proveedor antes de crearlo, porque este rechaza repetidos y el borrador necesita su id.

Cómo lo adaptas.

• Registro oficial: el SII vía tu proveedor en Chile, el padrón RUC de SUNAT en Perú, la validación de RFC del SAT en México.
• Datos extra: giro y comuna en Chile; actividad económica en Perú; régimen fiscal, código postal y uso del CFDI en México.

Cómo verificas que quedó bien. Sube una línea de 12 a 13 UF desde octubre: deben quedar dos filas, la anterior hasta septiembre y la nueva desde octubre. Septiembre cobra 12 UF y octubre, 13.

Paso 3 · El ciclo mensual

Qué resuelve. Convierte las líneas vigentes en los cargos del mes, exactos, sin duplicados y revisados antes de tocar al proveedor.

Qué construyes.

• Tablas: indices, que llena una tarea programada (3.2); cargos, uno por línea y período; y ciclos, uno por período, con fecha del documento, índice congelado, totales y estado.
• Vista «Calcular el ciclo»: vista previa seleccionable, descartes y totales.

Cómo funciona.

1. Eliges período (AAAA-MM) y fecha del documento (por defecto, fin de mes).
2. Se resuelve el índice de esa fecha: oficial o provisorio.
3. Se filtran las líneas elegibles y se explica cada descarte.
4. Se calculan montos, llave anti-duplicado y advertencias.
5. Guardas lo marcado: nacen los cargos, en pendiente, y el ciclo con el índice congelado.

• Elegibilidad: línea activa, vigencia que cubre el mes (comparada por AAAA-MM) y receptor activo.
• Índice: con un valor provisorio estimas; emites con el oficial.
• Monto: cantidad = unidades del índice; precio unitario = índice redondeado al peso; neto = cantidad × precio unitario.
• Impuesto: neto × tasa, redondeado (exenta: cero); total = neto + impuesto.
• Llave anti-duplicado: prefijo + período + receptor + cuenta + glosa + precio + unidad.
• Duplicados: antes de guardar se releen los cargos. Una llave existente sale «ya registrado»; repetida en el cálculo, queda la primera.

Ejemplo ficticio. 12 UF, documento del 31 de agosto, UF de $40.000,40. Precio unitario $40.000, neto $480.000, IVA 19 % $91.200, total $571.200. Llave: DEMO-202608-<RUT del receptor>-DEMO-RETAIL-PLAN-OPERACION-12-UF.

Por qué se diseñó así.

1. Calcular y emitir son etapas separadas: la revisión humana ocurre antes de cualquier efecto externo.
2. Precio y unidad entran a la llave porque dos líneas del mismo receptor con igual glosa y distinto precio compartían llave, y una quedó sin facturar.
3. Cambiar la fecha o el período descarta la vista previa, así cada monto guardado usa el índice congelado.

Cómo lo adaptas. Impuesto, documento e índice según tu país (3.3); redondeo al peso o al centavo; advertencias y valor provisorio que bloquean el guardado o solo avisan; y estado del ciclo escrito en cada paso o derivado de sus cargos.

Cómo verificas que quedó bien. Guarda un ciclo de prueba y recalcúlalo: todo debe salir «ya registrado» y cargos debe mantener su cantidad de filas. Cambia la fecha: la vista previa se descarta.

Paso 4 · Borradores y emisión

Qué resuelve. Convierte los cargos del ciclo en documentos tributarios electrónicos. Cada cargo sale una sola vez, con la fecha y el monto correctos.

Qué construyes.

• Vista «Borradores y emisión» sobre cargos, que guarda el id del documento en el proveedor, el folio y el último error. Muestra acciones por fila, confirmación, fallidos y bitácora.
• Un workflow por operación con el proveedor: buscar por llave, crear borrador, emitir, consultar estado, borrar borrador y traer el PDF.

Cómo funciona.

1. Borrador sin duplicados. Antes de crear, se busca en el proveedor la llave anti-duplicado del cargo, con igualdad exacta:
   • sin coincidencias → crea el borrador;
   • un documento emitido o en proceso → lo vincula al cargo;
   • un borrador suelto de un intento cortado → lo reemplaza;
   • varios, o uno de otro cargo → lo salta y deja la decisión a una persona.
2. Compuerta «emitible». El borrador congela fecha, monto, correo y OC/HES. «Emitir» se habilita si la fecha es la elegida, el neto calza con el del cargo (tolerancia de $1) y, si el cobro es indexado, el índice del día está publicado. Si algo difiere, la fila ofrece «Rehacer» o «Repreciar».
3. Confirmación explícita. Una tarjeta muestra cantidad, total y destinatarios; solo «Confirmar» emite.
4. Emisión, un documento por vez:

   para cada cargo confirmado:
     revalida contra la fila actual
     consulta el estado real en el proveedor
     si ya está emitido → márcalo emitido
     si sigue en proceso → espera
     si no → envía y consulta con esperas crecientes (unos 3 minutos)
   

5. Errores. Los transitorios (red, tiempo agotado, autoridad caída) se reintentan solos. Los de datos (identificador, folios agotados, monto) dejan el cargo en fallido hasta que lo corriges.

Ejemplo ficticio. Empresa Demo SpA crea el 28-sep un borrador de 12 UF para Cliente Demo Ltda. y luego elige el 30-sep como fecha. La fila bloquea «Emitir» y ofrece «Rehacer al 30-sep», con la UF de ese día.

Por qué se diseñó así.

1. El workflow de borrador solo sabe crear: un error de la app produce, como máximo, un borrador.
2. Antes de reintentar se consulta el estado, un documento por vez, porque reintentar algo ya emitido duplica una factura.

Cómo lo adaptas. Documento y autoridad según tu país (3.3); qué compara la compuerta y con qué tolerancia; confirmación de un rol, o doble firma sobre cierto monto; y referencias del cliente (OC, HES o centro de costo).

Cómo verificas que quedó bien. Crea los borradores del mes dos veces seguidas. En el portal del proveedor, cada llave debe tener un solo documento.

Paso 5 · El panel de facturación

Qué resuelve. Muestra la facturación neta mes a mes, incluida la emitida por otra vía: cuánto facturaste, a quién y cómo va el mes.

Qué construyes. La vista «Facturación», de solo lectura, y un workflow «listar documentos» que recorre todas las páginas del proveedor. Ninguna tabla nueva: el panel lee directo del proveedor.

Cómo funciona. Indicadores de facturado neto, promedio mensual, documentos y mes en curso; un gráfico de neto por mes, donde un clic abre el detalle por receptor y documento; y comparación año contra año y ranking por receptor, con filtro por año.

La nota de crédito se resta del mes de la factura que corrige. Ejemplo ficticio: Empresa Demo SpA factura $1.000.000 en agosto y en septiembre emite una nota de crédito de $200.000 sobre esa factura. Agosto muestra $800.000.

Por qué se diseñó así.

1. Lee del proveedor porque buena parte del histórico nunca pasó por la app.
2. Imputar la nota al mes corregido evita meses negativos.

Cómo lo adaptas. Fecha de inicio del histórico como parámetro; imputación al mes corregido (gestión) o al de emisión (tributario); y solo documentos aceptados por la autoridad.

Cómo verificas que quedó bien. Elige un mes cerrado y suma en el portal del proveedor sus facturas menos las notas que las corrigen. La barra debe dar la misma cifra.

Paso 6 · Flujo de caja desde la cartola

Qué resuelve. Arma tu flujo de caja real, mes a mes, desde la cartola. Separa la caja que genera el negocio de la que solo cambia de lugar.

Qué construyes.

• movimientos_banco (Paso 1): fecha, monto (+ abono, − egreso), glosa, n° de cartola, contraparte, categoría y marca operacional. clientes sirve para reconocer qué receptor pagó.
• Vistas: «Subir cartola», que lee, valida y carga; y «Flujo de caja», con saldo, flujo mensual, resumen por categoría y movimientos sin clasificar.

Cómo funciona.

1. Lectura. La app abre el Excel en el navegador, ubica textos ancla («SALDO INICIAL», «MONTO») y corta antes de los resúmenes, que repiten movimientos.
2. Cuadratura. Suma de movimientos = saldo final − saldo inicial, al peso. Con descuadre, «Cargar» se bloquea.
3. Deduplicación. Una cartola con número ya cargado se bloquea: «ya cargada».
4. Clasificación. Reglas en orden; gana la primera que calza:

5. Revisión. Un aviso cuenta los pendientes. Eliges la categoría en la fila y la marca operacional sale de ella.
6. Saldos. Saldo del mes = saldo anterior + movimientos del mes. Tesorería agrupa lo no operacional: inversiones, traspasos, aportes y retiros de socios.

Ejemplo ficticio. Empresa Demo SpA sube la cartola 12: saldo inicial $4.000.000, final $5.150.000.

• «<RUT de Cliente Demo> TRANSF», +2.380.000 → Cobranza.
• «PAGO S.I.I.», −850.000 → Impuestos.
• «TRANSF A EMPRESA DEMO SPA», −300.000 → Traspaso interno.
• «TRANSF A TERCERO», −80.000 → Sin clasificar.

Suma $1.150.000 = diferencia de saldos: cuadra. Flujo operacional: +$1.450.000. Tesorería: −$300.000.

Por qué se diseñó así.

• Cuadratura al peso antes de cargar: una fila mal leída descuadra todos los meses siguientes.
• Clasificar solo lo inequívoco: un sueldo, un pago a un tercero y un retiro de socio se ven iguales en la glosa, y adivinar distorsiona el flujo operacional.
• La cartola se queda en el navegador: solo viajan los movimientos que confirmas.

Cómo lo adaptas.

• Formato: Excel, CSV u OFX; monto con signo o columnas de egreso y abono.
• Glosa de impuestos: SII o TGR en Chile, SUNAT en Perú, SAT en México.
• Tolerancia: cero en pesos chilenos; ±0,01 en soles o pesos mexicanos.
• Llave de cartola: el número; cuenta + número con varias cuentas; fecha + monto + documento si el banco no numera.
• Categorías: reglas en una tabla editable.

Cómo verificas que quedó bien. Carga tres cartolas seguidas: el saldo final de la vista debe igualar al peso el de la última cartola. Resube la segunda: debe decir «ya cargada».

Paso 7 · Pagos y cuentas por cobrar

Qué resuelve. Cruza cada abono del banco con las facturas emitidas y dice cuáles quedaron pagadas. Así sabes cuánto te deben y a quién llamar primero.

Qué construyes.

• Workflow de lectura de facturas y notas de crédito desde el proveedor, y la columna folios_pagados en movimientos_banco.
• Vista «Quién pagó»: cada abono con su insignia: confirmado, a confirmar, pago en partes o sin factura que calce.
• Vista «Por cobrar»: una ficha por receptor con total, facturas, cuántas pasan de 30 días y «Copiar detalle».

Cómo funciona.

1. Qué entra. Los abonos operacionales, menos traspasos, rescates, aportes de capital, pagos revertidos y ventas de divisas; y las facturas emitidas con saldo sobre $1, netas de notas de crédito.
2. Match abono-factura:
   1. Aplica los folios fijados a mano.
   2. Por fecha, busca de 1 a 4 facturas del mismo receptor, emitidas antes del pago, que sumen el abono con ±$2.
   3. Si nada calza, junta hasta 4 abonos del receptor dentro de 45 días (pago partido).
   4. A lo que sobra, aplica 0,3 % de holgura por comisión.
   5. Con varias combinaciones posibles, elige la de fechas más juntas y marca «a confirmar».
3. Fijar a mano. «Fijar» guarda los folios del comprobante y los reserva antes del match; con el campo vacío, vuelve al automático.
4. Antigüedad. Días desde la emisión: hasta 30, al día; de 31 a 60, amarillo; sobre 60, rojo.

Ejemplo ficticio. Cliente Demo Ltda. debe la F-101 ($238.000, 3 de marzo), la F-102 ($357.000, 10 de marzo) y la F-103 ($357.000, 12 de marzo), y paga $595.000. Calzan F-101 + F-102 (7 días) y F-101 + F-103 (9 días): la app propone la primera, «a confirmar». El comprobante dice F-101 y F-103, finanzas fija «101,103» y la F-102 pasa a cobranza.

Por qué se diseñó así.

• La persona manda sobre la heurística: el comprobante del banco decide cuando la aritmética empata.
• El desempate por fechas más juntas se validó contra un certificado de pago real.
• Las facturas anteriores a la primera cartola quedan «no verificables», porque pudieron pagarse en un mes sin datos.

Cómo lo adaptas.

• Holguras y ventana, según tus comisiones y plazos.
• Retenciones: en Chile, la factura de compra que emite el cliente se cobra por el neto; en Perú, descuenta la detracción o la retención del IGV.
• Evidencia: en México, el complemento de pago del CFDI ya indica qué folios salda.
• Antigüedad desde el vencimiento, con tramos 0-30, 31-60, 61-90 y +90.
• Trazabilidad: quién fijó cada pago y con qué comprobante.

Cómo verificas que quedó bien. Carga el ejemplo: el abono aparece «a confirmar» con dos alternativas. Fija «101,103» y recalcula: queda «confirmado» y la F-102 sigue por cobrar con sus días.

Paso 8 · Contabilidad automática

Qué resuelve. Arma libro diario, mayor y balance del año desde los datos que ya tienes, y lista qué falta para cerrar.

Qué construyes.

• Fuentes: ventas, facturas de gastos, banco, tarjeta, sueldos y préstamos.
• Catálogos: el plan de cuentas de tu contador y el asiento de apertura.
• Vista «Contabilidad»: Balance, Libro diario, Mayor, Préstamos, Fuentes y «Recalcular».

Cómo funciona. Cada hecho genera su asiento:

Ejemplo ficticio. Empresa Demo SpA factura $1.190.000: Debe por cobrar $1.190.000; Haber ingresos $1.000.000 e IVA $190.000. Al cobrar: Debe banco, Haber por cobrar.

• Impuesto al valor agregado: una cuenta neta que suma el de ventas, resta el de compras y baja con el formulario mensual (F29 en Chile, formulario 621 en Perú, declaración mensual al SAT en México).
• Préstamos, sistema francés: tasa mensual = (1 + tasa anual)^(1/12) − 1, con cuota fija: $12.000.000 al 12 % anual en 24 cuotas dan $561.450. Separa lo que vence en 12 meses y devenga el interés de cada cuota vencida.
• Pendientes de cierre: pasivos con saldo deudor, movimientos sin cuenta, facturas en moneda extranjera sin tipo de cambio y sueldos estimados.

Por qué se diseñó así.

• Todo se recalcula desde las fuentes: cada factura o cartola nueva actualiza el balance.
• El gasto nace con la factura y el pago solo baja la deuda, así cada gasto cuenta una vez.
• El asiento con debe distinto del haber queda fuera del diario y se reporta, así el hueco queda a la vista.

Cómo lo adaptas.

• Plan de cuentas, apertura, formularios y mapa categoría → cuenta, en tablas editables; el ejercicio, como parámetro.
• Amortización francesa, alemana o al vencimiento, con reajuste por UF o UDI si aplica.
• Permiso de solo lectura sobre las fuentes.

Cómo verificas que quedó bien. Registra en el banco el pago de un gasto sin su factura: «Por pagar» aparece en «Pasivos con saldo deudor». Carga la factura, recalcula y el aviso desaparece.

Paso 9 · Presupuesto y proyección

Qué resuelve. Reemplaza la planilla de presupuesto: proyecta mes a mes cuánto facturar para cumplir una meta, qué costos corren, cuánto impuesto sale y cuánta caja queda.

Qué construyes.

• costos_presupuesto: concepto, categoría, monto mensual, desde y hasta (AAAA-MM; «hasta» vacío = sin fin), activo y afecto a IVA.
• config: una fila por supuesto (crecimiento, ingreso base, horizonte, saldo inicial, tasas, desfase de pago). Todos ven los mismos.
• Vista «Presupuesto»: supuestos, tendencia, KPIs, alerta de caja, resultado, impuesto y clientes a cerrar, con datos reales de los Pasos 5 y 6.

Cómo funciona. Cada mes del horizonte:

1. Ingreso = ingreso anterior × (1 + crecimiento).
2. Costos vigentes = activos con «desde» ≤ mes ≤ «hasta».
3. Impuesto = máx(0, IVA de ventas − IVA de gastos) + anticipo sobre ventas.
4. EBITDA = ingreso neto − costos netos de IVA.
5. Caja = cobrado con IVA − costos − impuesto pagado. El saldo se acumula.

Ejemplo ficticio. Empresa Demo SpA facturó $10.000.000 netos en julio y supone 5 % mensual. Para agosto:

• Ingreso meta: $10.500.000. Sueldos + software neto: $6.500.000.
• Impuesto: IVA neto (1.995.000 − 95.000) + anticipo de 1 % = $2.005.000.
• EBITDA: $4.000.000 (38 %). Flujo de caja: $3.895.000.
• La brecha de $500.000, con un plan de $250.000, son 2 clientes nuevos.

Tendencia y escenarios. La app compara el crecimiento compuesto de los meses cerrados con el promedio simple, y avisa si difieren más de 15 puntos. Cambia un supuesto o desactiva un costo y todo se recalcula.

Por qué se diseñó así.

• La meta se ve distinta del dato. El mes en curso queda fuera de la tendencia, porque un mes incompleto simula una caída.
• El impuesto sale de las ventas. Los sueldos no llevan IVA, así que el impuesto crece con las ventas.
• Resultado y caja van separados. El IVA se cobra al cliente y se traspasa al fisco: la caja lo incluye y el EBITDA lo excluye.

Cómo lo adaptas.

• Anticipo mensual: PPM en Chile, pago a cuenta de renta en Perú, pago provisional de ISR en México. Moneda del precio: UF en Chile; soles o dólares en Perú; pesos o UDI en México.
• Otras perillas: horizonte, desfase de pago (0 o 1 mes), costos variables como porcentaje de ventas, saldo mínimo de alerta y escenarios guardados.
• Buena práctica: restringe el acceso a la vista, porque muestra sueldos.

Cómo verificas que quedó bien. Carga tu planilla actual. Los costos de cada mes deben calzar al peso, y el impuesto de dos meses reales, quedar a menos de 1 % de lo pagado. Luego agrega un costo con «desde» en el tercer mes: debe aparecer solo desde ahí.

3. Conecta tus sistemas externos

Tu herramienta habla con el proveedor y con las fuentes oficiales de índices.

3.1 El workflow como proxy seguro

La app llama a un workflow, y este llama al proveedor desde el servidor de Puente. Así resuelves dos bloqueos: muchos proveedores aceptan llamadas solo desde su dominio (CORS), y el token quedaría expuesto en el código de la app.

1. Recibir: webhook síncrono con los parámetros mínimos
2. Validar el formato de cada parámetro; si falla, responder error
3. Llamar al proveedor con ruta fija y el token guardado en el servidor
4. Responder a la app en una forma estable

• Un workflow por intención: crear borrador, emitir, consultar estado y bajar el PDF van por separado. El de borradores lleva «emitir = falso» fijo en el nodo, y la emisión, irreversible, vive aislada.
• Webhook síncrono con timeout: devuelve la respuesta del workflow. Billing OS corta cada llamada a los 120 segundos, porque la primera ejecución puede tardar decenas de segundos, y muestra el error.
• Prueba de circuito: arranca con un workflow de solo lectura («¿quién soy?»).
• Estados normalizados a los tuyos (borrador, procesando, emitido, fallido): así cambias de proveedor sin tocar la app.
• Token en un solo lugar, para rotarlo fácil, o una conexión administrada donde exista (Gmail, Google Sheets).

3.2 Tarea programada para los índices

Un índice mal cargado termina en facturas rechazadas, y algunas fuentes repiten sin avisar el último valor para fechas futuras. Por eso indices la llena un workflow programado:

1. Correr los días 10 al 15 a las 08:00 (la UF se publica el día 9; los días extra reintentan)
2. Leer las fechas ya cargadas
3. Bajar el índice de dos fuentes públicas y revisar cantidad y rango
4. Insertar solo los días nuevos donde ambas coinciden (diferencia menor a 0,005)
5. Si todo se descartó, marcar la corrida como fallida

La app etiqueta cada valor como oficial o provisorio, y con uno provisorio bloquea la emisión en esa unidad.

3.3 Variantes por país

Valida cada dato con tu proveedor y tu contador.

El mismo patrón sirve con cualquier sistema. Si tu facturación sale de Bsale, tu conciliación vive en Chipax o tu contabilidad en Defontana, cada operación que la herramienta necesite (leer clientes, emitir, bajar documentos, traer movimientos) se arma como un workflow propio con el token de ese sistema del lado del servidor.

Nodos nativos útiles: Gmail (enviar facturas, leer cartolas), Google Sheets y WhatsApp (cobranza y aprobaciones), WooCommerce, Mercado Libre, Multivende o Bsale (órdenes que alimentan la facturación) y un agente de IA que clasifica movimientos sin acceso al webhook de emitir.

4. Seguridad y publicación

El navegador ve todo el código de la app: su key, los IDs de tablas y webhooks, y las filas de toda tabla con permiso de lectura. El token del proveedor, sus rutas y las validaciones quedan en el servidor, y la key de administración de tu equipo, fuera de toda app.

4.1 Permisos mínimos por tabla

1. Arma la matriz vista × tabla: qué lee, crea, actualiza o borra cada vista. La app tiene una sola key, con la suma de esos permisos.
2. Da a cada tabla solo lo que usa: indices va en solo lectura, porque la escribe la tarea programada.
3. Borra solo los cargos que nunca llegaron al proveedor; en el resto, usa baja lógica.
4. Tras cada cambio de permisos, prueba cada tabla con una lectura real.

Trata la key como pública: todo permiso que le des lo usa quien lea el código.

4.2 Tablas sensibles

Sueldos, préstamos a socios y datos personales quedan fuera del alcance de la key:

• Workflow que valida en el servidor: recibir → validar el acceso → si falla, «acceso denegado» → recién ahí leer o escribir, con intentos limitados. Úsalo también para emitir: la ruta fija define qué hace el webhook, y la validación, quién lo usa.
• App aparte por rol, con su propia key.
• Cifrado en reposo, decidido al crear la tabla: solo un workflow autorizado descifra, y las columnas cifradas quedan fuera de filtros y cruces. Deja en claro el identificador, el período y la fecha.

4.3 Antes de publicar

• Apaga los workflows sin uso. Cada webhook activo es una puerta.
• Errores visibles. Si una fuente falla, la pantalla lo dice: un «0» se distingue de un «no pude leer».
• Datos ficticios en comentarios, ejemplos y valores por defecto, y los parámetros en config.
• Confirma lo irreversible: publicar, regenerar la key, migrar una tabla y activar un workflow.

5. Adáptalo a tu empresa

Por país: la tabla de 3.3.

Por industria. Servicios B2B recurrentes: líneas con vigencia, índices y referencias del cliente. Comercio electrónico: cada orden genera su boleta o factura. Operación en planillas: Google Sheets como origen, con escritura idempotente.

Por tamaño. Arranque: una app, captura manual y emisión cargo por cargo. Pyme: tareas programadas, lecturas paginadas (500 filas por consulta) y cargas masivas. Mediana: apps por rol, cifrado desde el diseño, cargas pesadas en workflows y atención al límite de 60 consultas por minuto por key.

6. Checklist final y glosario

• Permisos por tabla iguales a la matriz vista × tabla.
• Tablas sensibles cifradas, en otra app o detrás de un workflow que valida.
• Un workflow por intención, con ruta fija, token en el servidor y timeout en la app.
• Emisión separada del borrador, y llave anti-duplicado buscada en el proveedor antes de crear.
• Índices cargados por tarea programada con dos fuentes, y cada fuente que falla muestra su error.
• Baja lógica, lecturas paginadas y workflows sin uso apagados.
• Un ciclo completo con Empresa Demo SpA y datos ficticios, de la línea al borrador.

Glosario

• Borrador: documento creado en el proveedor que la autoridad todavía no ve.
• Cargo: el cobro de una línea en un período; es lo que se emite.
• Cartola: el extracto de movimientos de tu cuenta bancaria.
• Ciclo: la facturación de un período, del cálculo de los cargos a su emisión.
• Cuenta comercial: área o servicio de un receptor que compra con su propio precio y referencias.
• Documento tributario electrónico: factura, boleta o nota validada por la autoridad.
• Línea: lo que cobras a una cuenta comercial, con glosa, precio, unidad, periodicidad y vigencia.
• Llave anti-duplicado: identificador de un cargo armado con su contenido, para que repetir la emisión deje una sola factura.
• OC y HES: orden de compra y hoja de entrada de servicios, referencias que el cliente exige para pagar.
• Proveedor de facturación electrónica: el servicio que emite tus documentos ante la autoridad; en esta guía, «el proveedor».
• Receptor: la empresa a la que emites el documento. Cada fila de clientes es un receptor.
• Webhook síncrono: dirección que arranca un workflow y espera su respuesta.