Johann
27 KiB
Propuesta Comercial — Plataforma de Automatización Financiera (Balam)
Para: Balam De: [Tu nombre] Fecha: Mayo 2026 Vigencia: 30 días
1. Entendimiento del proyecto
El problema, en palabras del equipo directivo
"El proceso está tan desvinculado… pasa por varias manos… cada parte humana se está equivocando."
Esto es lo que escuché en la llamada con CEO, CFO y CTO: el dolor no es técnico, es operativo y costoso. Cada handoff manual entre nómina, facturación, cobranza, conciliación y contabilidad introduce error humano que se paga en dinero perdido, retrabajo y deterioro de relación con clientes estratégicos.
Lo que existe hoy
- BIND ERP (facturación + contabilidad con PAC integrado)
- BUK (HR, contratos, nómina, vacaciones — core de gestión de talento)
- Jira (gestión de proyectos y servicios con clientes)
- 3 bancos en PDF (2 MX + IBC Bank Texas)
Estos sistemas funcionan individualmente, pero no conversan entre sí. La operación financiera vive en el espacio entre ellos — y hoy ese espacio se llena con trabajo manual y propenso a error.
Lo que propongo construir
Una capa de operaciones financieras encima de los sistemas existentes, no un reemplazo. BIND sigue siendo fuente de verdad para facturación y contabilidad; BUK sigue siendo el core de HR; Jira sigue gestionando proyectos. La plataforma orquesta el flujo financiero que hoy nadie tiene:
MVP (6 semanas):
- Cobranza automatizada con reglas de negocio (lista blanca ACUNTIA + top 3)
- Conciliación bancaria sobre PDFs (3 bancos, incluyendo IBC Texas) usando IA para parsing
- Dashboard consolidado de CxC y vencimientos
- Pago con link Stripe — nuevo requerimiento confirmado
- Alertas y reportes programados
Visión end-to-end (Fase 2-3): La arquitectura del MVP queda preparada para cerrar el ciclo completo que el equipo directivo describió en la llamada:
Jira (horas) → BUK (nómina) → Plataforma → Factura → Cobranza → Conciliación → Asiento
Cuando BIND y BUK habiliten APIs (o decidan invertir en Belvo / Plaid / conectores), la plataforma absorbe esos nuevos disparadores sin reescribir lo construido. Hoy importamos archivos; mañana escuchamos webhooks. El motor de orquestación es el mismo.
El éxito del proyecto se mide en
- Reducción ≥ 70% de errores manuales contables
- Reducción ≥ 60% del tiempo de conciliación bancaria
- Visibilidad en tiempo real del estado financiero para dirección
- MVP funcional con flujo end-to-end de cobranza + conciliación + pago en 6 semanas
- Cero riesgo sobre la relación con clientes estratégicos (lista blanca dura)
Escala operativa (referencia)
- 45 colaboradores en nómina + 5 freelancers
- ~50 facturas emitidas al mes
- 3 bancos (2 MX + IBC Bank Texas)
- 2 jurisdicciones fiscales (México + Texas, tax estándar en MVP)
- Stakeholders operativos: contacto técnico + gerente administrativo (con visibilidad ejecutiva de CEO/CFO/CTO)
2. Modelo de colaboración
2.1 Modalidad: Time & Materials con presupuesto por fase
Trabajo bajo modelo de horas reales con tarifa transparente, no precio cerrado. Razón: el alcance real de las integraciones (BIND, bancos, SAT) sólo se conoce al inspeccionar APIs y datos en vivo; un precio fijo obligaría a inflar el presupuesto para cubrir incertidumbre, encareciendo el proyecto innecesariamente.
A cambio, ofrezco:
- Rango estimado por fase (mín-máx en horas) acordado por escrito antes de iniciar cada fase
- Soft cap por fase: si proyecto rebasar el rango máximo, paro y conversamos antes de continuar — nunca hay "sorpresas" en factura
- Reporte semanal de horas trabajadas con desglose por tarea (vía Notion / Linear / sheet compartido)
- Demo semanal del avance entregado
2.2 Toolchain moderno (Claude Code + revisión humana)
Trabajo con un toolchain de desarrollo asistido por IA (Claude Code de Anthropic) como acelerador. Esto es información que Balam debe saber por transparencia y por compliance:
- Beneficio para Balam: ranges de horas estimados arriba son conservadores; con esta metodología tienden al extremo bajo del rango sin pérdida de calidad. Mayor cobertura de tests, mejor documentación y refactor más frecuente quedan dentro del mismo presupuesto.
- Responsabilidad humana: todo código entregado es revisado y validado por mí. La IA es asistente, no es quien firma el código. Yo soy responsable de cada línea que se mergea a
main. - Datos de Balam quedan fuera: ningún dato real de Balam (clientes, montos, credenciales, XMLs reales, estados de cuenta) se envía a modelos externos. Se trabaja con datos sintéticos generados a partir de la estructura, no del contenido. Las credenciales viven en gestores de secretos cifrados; nunca se pegan en prompts.
- Compliance: la metodología cumple con la política habitual de proveedores que manejan datos financieros (no entrenamiento sobre datos del cliente, no telemetría de datos del cliente, código en repositorio del cliente desde día 1).
- Auditabilidad: las decisiones de arquitectura quedan registradas en ADRs versionados (
docs/adr/), exactamente como si fueran de un humano.
2.3 Dedicación: medio tiempo
Trabajaré medio tiempo (~20 h/semana) sobre el proyecto. El calendario de 6 semanas asume esa dedicación; con eso el budget total es de 110–140 horas.
2.4 Tarifa
600 MXN / hora trabajada + IVA (facturación CFDI 4.0).
2.5 Facturación
- Semanal, los viernes, por las horas trabajadas la semana anterior
- Pago a 7 días naturales vía transferencia
- Cada factura incluye anexo con detalle de horas por tarea/fase
2.6 Comunicación
- Standup async 2-3 veces por semana (texto + Loom corto en Slack/WhatsApp) — qué hice, qué sigue, bloqueadores
- Demo semanal (30 min, viernes) con el contacto técnico y el gerente administrativo
- Sesión técnica quincenal (1 h) — decisiones de arquitectura, validación de reglas de negocio
- Disponibilidad para llamadas urgentes con 24 h de aviso en horario laboral (9-18 hrs CST)
3. Alcance — MVP en 6 semanas (medio tiempo)
Filosofía: Un MVP entrega valor real lo antes posible con el alcance mínimo viable, no con todo lo deseable. Lo que no entre en estas 6 semanas vive en el roadmap de Fase 2 (§4) y se cotiza al cerrar el MVP, con datos reales de uso que justifiquen las prioridades.
Posicionamiento: la plataforma es una capa de operaciones financieras encima de BIND, no un reemplazo. BIND sigue siendo la fuente de verdad para facturación, timbrado CFDI y contabilidad. La plataforma orquesta cobranza, conciliación, dashboard, pagos con link y alertas.
Fase 0 — Discovery + Setup (Semana 1 · 18 – 22 h)
Objetivo: Validar supuestos técnicos críticos (BIND, PDFs bancarios, Stripe), preparar la infraestructura Azure y dejar el repositorio listo.
Entregables:
- Inspección del formato de export de BIND (estructura del archivo, frecuencia, contenido — facturas, clientes, catálogo)
- Recolección de muestras reales (anonimizadas) de PDFs de los 3 bancos
- Validación de viabilidad de parsing con Claude API sobre 2-3 PDFs reales por banco
- Cuenta Azure creada con recursos base (App Service + Postgres + Storage) y staging vacío
- Repositorio monorepo + CI/CD + workflow Claude Code configurado con guardrails de seguridad
- Cuenta Stripe MX creada y validada
- Documento de supuestos validados + plan refinado de Fases 1-4
- Manual de marca recibido y aplicado a maquetas iniciales
Fase 1 — Plataforma base + Sincronización BIND (Semanas 2-3 · 30 – 38 h)
Objetivo: Plataforma funcional que ingiere facturas de BIND, mantiene catálogo de clientes y rastrea estatus.
Entregables:
- Backend con autenticación, roles (Finanzas / Dirección / Operaciones / Admin), audit log universal
- Multi-tenancy en schema (
tenant_id+ RLS) — preparado sin onboarding self-service - Importador de archivo de BIND (clientes, facturas, productos) con dedupe y validación
- Modelo central de facturas con estados (Emitida / Pagada / Vencida / Cancelada)
- Visualización multimoneda MXN y USD con TC diario del DOF (snapshot al momento de la factura)
- UI: listado de facturas con filtros, búsqueda, drill-down a detalle
- Gestión de catálogo de clientes con bandera
auto_reminder_enabledpara lista blanca - Branding aplicado (logo + colores del manual de marca)
- Manual de usuario v1
Importante: la plataforma no emite CFDI; eso lo sigue haciendo BIND con su PAC integrado. Si en el futuro Balam quiere emitir desde la plataforma, se evalúa en Fase 2 (requiere contratar PAC adicional o desarrollar conector contra BIND).
Fuera de MVP: EUR, integración BUK, sincronización en vivo con BIND (mientras BIND no exponga API, se trabaja con export programado).
Fase 2 — Cobranza + Dashboard + Pago con link (Semana 4 · 25 – 32 h)
Objetivo: Cobranza semi-automatizada con visibilidad real y un canal moderno de cobro.
Entregables:
- Registro manual de pagos + asociación a facturas (totales y parciales)
- Editor de template para correos de cobranza (markdown + variables)
- Motor de recordatorios automáticos por email (cron + worker idempotente)
- Lista blanca dura: ACUNTIA + Top 3 jamás reciben recordatorio automático (configurable)
- Recordatorio 5 días antes del vencimiento (configurable)
- Log de comunicaciones enviadas con UI de revisión
- Pago con link (Stripe Checkout):
- Generación de link de pago por factura
- Envío del link junto con el recordatorio de cobranza
- Webhook que marca factura como pagada al recibir confirmación de Stripe
- Soporte para tarjeta y SPEI vía Stripe
- Dashboard v1: CxC totales y por cliente, vencidas, próximas a vencer, exportación a Excel
Fuera de MVP: domiciliación / pagos recurrentes (Stripe Subscriptions o equivalente, requiere onboarding del cliente y manejo de mandatos — se cotiza en Fase 2). Cash-flow proyectado 30/60/90.
Fase 3 — Conciliación bancaria por PDF (Semana 5 · 22 – 28 h)
Objetivo: Eliminar conciliación manual sobre los 3 PDFs bancarios.
Entregables:
- Importación de estados de cuenta en PDF (upload manual por el equipo)
- Extracción estructurada vía Claude API (movimientos: fecha, monto, concepto, referencia)
- Una pipeline por banco con prompts validados sobre muestras reales (incluyendo IBC Bank Texas)
- Validación de totales (suma de movimientos vs. resumen del PDF) para detectar extracciones incorrectas
- Dedupe por hash del registro extraído
- Motor de conciliación:
- Match exacto (monto + referencia + ventana de fecha) → automático
- Match por alias de cliente → automático con flag de revisión
- Sin match → cola de revisión humana
- Detección básica de duplicados y traspasos internos entre cuentas propias
- Dashboard de movimientos no conciliados
Por qué Claude API para parsing: los formatos de PDF varían por banco y dentro del mismo banco a lo largo del tiempo; un parser hardcodeado por banco rompe con cada cambio. Con Claude se genera salida estructurada robusta a variaciones, con costo ~$0.01-0.05 USD por página y validación automática contra totales. Anthropic API por default no entrena con los datos enviados; los PDFs se procesan con datos reales bajo este compromiso contractual.
Fuera de MVP: integración en vivo con bancos (Belvo / Plaid), detección de anomalías avanzada (z-score, vendor nuevo, horarios atípicos), scraping automatizado del portal de IBC.
Fase 4 — Asientos contables + Cierre del MVP (Semana 6 · 15 – 20 h)
Objetivo: Cerrar el flujo de operaciones con export para BIND y entrega formal.
Entregables:
- Reporte de pagos conciliados exportable a Excel/CSV en formato compatible con BIND (para carga manual por el contador)
- Reporte mensual de CxC y CxP
- Backups automáticos + plan de recuperación documentado
- Endurecimiento de seguridad final (helmet, rate limiting, RBAC granular, modo dry-run para operaciones contra BIND)
- Documentación técnica: README, runbook operativo, ADRs
- Sesión de capacitación grabada (1.5-2 h) con contacto técnico y gerente administrativo
- Handoff + soporte post-lanzamiento de 2 semanas (corrección de bugs)
Importante: los asientos contables completos los sigue generando BIND. La plataforma exporta pagos conciliados y movimientos clasificados que el contador sube a BIND. Generación de asientos automáticos contra BIND vía API queda para Fase 2 (depende de que BIND habilite API).
Resumen de estimaciones
| Fase | Entregable principal | Rango (horas) | Rango (MXN) |
|---|---|---|---|
| 0 | Discovery + Setup Azure | 18 – 22 | $10,800 – $13,200 |
| 1 | Plataforma + Sync con BIND | 30 – 38 | $18,000 – $22,800 |
| 2 | Cobranza + Dashboard + Pago link | 25 – 32 | $15,000 – $19,200 |
| 3 | Conciliación PDF (Claude API) | 22 – 28 | $13,200 – $16,800 |
| 4 | Reportes + cierre | 15 – 20 | $9,000 – $12,000 |
| Total MVP | 110 – 140 horas | $66,000 – $84,000 |
Cifras antes de IVA. Tiempo calendario: 6 semanas con dedicación medio tiempo (~20 h/semana, con flex hasta 25 h en semanas pico). Por el uso de toolchain asistido por IA (ver §2.2), la expectativa real es caer cerca del extremo bajo de cada rango, salvo sorpresas en parsing de PDFs bancarios o exports de BIND.
4. Fase 2 (post-MVP) — Roadmap propuesto
No incluido en esta propuesta; se cotiza al cerrar MVP, priorizando con base en lo que se observe en uso real.
Cerrar el flujo end-to-end (la visión original del equipo directivo)
- Jira → horas por colaborador-cliente ingestadas a la plataforma
- BUK → nómina aprobada como trigger automático de factura al cliente
- Plataforma → BIND: generación automática de factura tras evento de nómina (caso de uso #1 del PRD inicial)
- Plataforma → BIND: asientos contables automáticos tras conciliación
- Ciclo completo:
Jira → BUK → Factura → Cobranza → Conciliación → Asiento
Integraciones bancarias y ERP
- Integración en vivo con bancos vía Belvo (MX) — elimina la carga manual de PDFs
- Plaid u OCR automatizado para IBC Bank si se valida que el cliente puede compartir credenciales
- Conector contra BIND cuando habilite API (eliminar export/import manual)
- Integración con BUK (nómina, contratos, freelancers) cuando exponga API
- Integración con Jira para horas trabajadas → input de facturación
Funcionalidad financiera
- Soporte de EUR (clientes europeos)
- Cash-flow proyectado a 30/60/90 días
- Manejo automático de pérdidas/ganancias cambiarias
- Domiciliación y pagos recurrentes vía Stripe Subscriptions (pólizas, mensualidades)
- Detección avanzada de anomalías (z-score, vendor nuevo, horarios atípicos, frecuencia)
- Compliance avanzado para operación en Texas (más allá de tax estándar)
Plataforma y producto
- Agentes IA / LLM para clasificación de transacciones y sugerencias de match
- Portal de cliente self-service (consulta de facturas, descargas, historial de pagos)
- App móvil para captura de tickets físicos
- Multi-tenancy comercial (onboarding self-service, billing) para comercializar como producto
- Compliance avanzado: NOM-151, evidencia digital, auditoría fiscal Texas
5. Costos operativos (a cargo de Balam)
Estos no son honorarios míos; son servicios de terceros que la plataforma requiere:
| Servicio | Concepto | Costo estimado |
|---|---|---|
| Azure App Service (Linux, B1/B2) | App + worker | $13 – $55 USD/mes |
| Azure Database for PostgreSQL | Base de datos productiva | $25 – $80 USD/mes |
| Azure Blob Storage | PDFs bancarios, exports | $1 – $5 USD/mes |
| Sentry + uptime monitoring | Observabilidad | $0 – $26 USD/mes |
| Email transaccional (Resend) | Recordatorios + links de pago | $0 – $20 USD/mes |
| Claude API (parsing de PDFs bancarios) | ~3 PDFs/mes × ~20 págs c/u | $5 – $20 USD/mes |
| Stripe (pago con link) | Comisión por transacción | 3.6% + $3 MXN por pago tarjeta · ~$3 MXN por SPEI |
| PAC para CFDI | Ya incluido en BIND | $0 — no costo adicional |
| Total mensual MVP | $45 – $210 USD/mes + comisiones Stripe |
En Fase 2, al activar integración bancaria en vivo se suma Belvo ($200 – $500 USD/mes) y/o Plaid ($0.30 – $1 USD por cuenta/mes). Costos de Azure pueden optimizarse evaluando reserved instances después de validar consumo real.
6. Supuestos críticos
Si alguno no se cumple, replanteamos esa fase:
- Export programable o periódico de BIND disponible (facturas + clientes) en Fase 0; formato documentable.
- PDFs reales (anonimizados) de los 3 bancos compartidos al inicio de Fase 0 para validar parsing.
- Acceso al portal de IBC Bank Texas para que el equipo descargue PDFs manualmente y los suba a la plataforma.
- PAC de BIND maneja los volúmenes actuales y futuros sin costo adicional; la plataforma no timbra facturas en MVP.
- Cuenta Azure de Balam (o autorización para crearla a nombre de Balam) disponible al inicio de Fase 0.
- Cuenta Stripe MX verificada (RFC + datos bancarios) antes de iniciar Fase 2.
- Manual de marca compartido al inicio de Fase 0.
- Reglas de negocio finales validadas en Fase 0 — especialmente lista blanca de clientes, ciclos de cobranza, frecuencia de export de BIND.
- Dos stakeholders disponibles (contacto técnico + gerente administrativo) con capacidad de resolver bloqueadores en <48 hrs.
- Producción es el único ambiente disponible (sin sandbox de BIND ni BUK). La plataforma operará con modo dry-run cuando exista riesgo de afectar BIND, con confirmación explícita del usuario antes de cualquier escritura.
- Acuerdo de uso de Claude API para parsing de PDFs bancarios firmado (compromiso de no entrenamiento sobre datos del cliente, ya estándar en Anthropic API).
7. Lo que entrego más allá de código
- Código en repositorio del cliente (GitHub) desde el día 1 — Balam es dueño del IP
- Documentación técnica viva en
/docsdel repo - Pruebas automatizadas para flujos críticos (facturación, conciliación)
- Pipeline CI/CD funcionando, despliegues con un clic
- Backups automatizados y plan de recuperación documentado
- Sesión de transferencia de conocimiento grabada
- Soporte post-lanzamiento de 2 semanas incluido (correcciones de bugs, no nuevo alcance)
8. Lo que no incluye esta propuesta
- Diseño visual / branding (puedo usar shadcn/ui + diseño funcional; si quieren branding pleno, sumar diseñador)
- Compra de licencias de software de terceros (PAC, agregadores, hosting)
- Cambios de proceso interno o capacitación de cambio organizacional más allá de la sesión técnica
- Integraciones no listadas (Jira, CRM, etc.) — cotizables por separado
- Garantía contra cambios fiscales del SAT que requieran rework mayor (cotizables como mantenimiento)
9. Garantía y retención
- Bugs en funcionalidad entregada: cobertura sin costo por 30 días después de entrega de cada fase.
- Cambios de alcance: se documentan como Change Request, se estiman, y se aprueban antes de ejecutar.
- IP y código: propiedad de Balam desde el primer commit. Retengo derecho de mencionar el proyecto en mi portafolio sin revelar información confidencial.
- Calidad del código generado con asistencia de IA: cualquier defecto cae bajo la misma garantía. La responsabilidad final del código es mía, sin importar la herramienta usada para escribirlo.
10. Próximos pasos
- Reunión de kickoff (1 h) para revisar esta propuesta y resolver dudas
- Firma de acuerdo (contrato de prestación de servicios + NDA si aplica)
- Anticipo de 30 horas de Fase 0 para arrancar Discovery
- Inicio inmediato — entrega del MVP en 6 semanas
Contacto [Tu nombre] [Tu email] · [Tu WhatsApp] Monterrey, NL
Anexo A — Trazabilidad PRD ↔ MVP (6 semanas)
Este anexo mapea cada funcionalidad y requerimiento del PRD oficial de Balam contra el alcance comprometido en las 6 semanas del MVP. Sirve como referencia rápida para alinear expectativas y para discutir explícitamente lo que entra, lo que entra parcial y lo que se difiere a Fase 2.
Leyenda: ✅ Cubierto · ⚠️ Parcial · ❌ Diferido a Fase 2
A.1 Funcionalidades del MVP (PRD §3.1)
Facturación
| Funcionalidad PRD | Cobertura | Detalle |
|---|---|---|
| Generación automatizada de facturas | ❌ | La emisión sigue en BIND con su PAC. La generación desde eventos de negocio (Jira→BUK→Factura) depende de APIs que esos sistemas no exponen hoy — Fase 2. |
| Integración multimoneda para clientes internacionales (USD sin IVA) | ⚠️ | MXN y USD con TC del DOF y snapshot al momento de la factura (Fase 1). EUR queda fuera del MVP. |
| Descarga automática de facturas / reporte | ✅ | Listado con filtros, búsqueda y export Excel (Fase 1 + Fase 4). |
Cobranza
| Funcionalidad PRD | Cobertura | Detalle |
|---|---|---|
| Registro automático de pagos | ⚠️ | Automático vía webhook de Stripe para pagos con link. Pagos a cuenta bancaria se concilian desde el PDF en Fase 3, no en vivo. |
| Identificación de pagos por cliente | ✅ | Asociación a facturas, soporte de pagos parciales y completos (Fase 2). |
| Seguimiento de CxC con template de correo + lista blanca ACUNTIA y Top 3 (gestión humana) | ✅ | Lista blanca dura configurable, editor de template con variables, log de comunicaciones, recordatorio configurable (default 5 días antes de vencer) (Fase 2). |
Conciliación bancaria
| Funcionalidad PRD | Cobertura | Detalle |
|---|---|---|
| Conciliación automática pagos vs. facturas | ✅ | Match exacto, match por alias de cliente, cola de revisión humana para no-match (Fase 3). |
| Integración con estados de cuenta (3 bancos, incluye IBC Texas) | ⚠️ | PDF upload manual + extracción estructurada vía Claude API con validación contra totales del PDF. Integración bancaria en vivo (Belvo/Plaid/OCR portal IBC) → Fase 2. |
| Identificación de discrepancias | ✅ | Dedupe por hash, detección básica de duplicados y traspasos internos entre cuentas propias (Fase 3). |
Contabilidad
| Funcionalidad PRD | Cobertura | Detalle |
|---|---|---|
| Generación automática de asientos contables (ERP BIND) | ❌ | Depende de que BIND habilite API. En MVP se entrega export en formato BIND que el contador sube manualmente — Fase 2 para conector en vivo. |
| Integración básica con sistema contable existente | ⚠️ | Vía export/import programado, no API en vivo. |
Reportes y alertas
| Funcionalidad PRD | Cobertura | Detalle |
|---|---|---|
| Dashboard de estado financiero | ✅ | CxC totales y por cliente, vencidas, próximas a vencer, exportable (Fase 2). |
| Alerta — pagos pendientes | ✅ | Fase 2 |
| Alerta — errores en conciliación | ✅ | Fase 3 |
| Alerta — facturas no cobradas | ✅ | Fase 2 |
A.2 Requerimientos funcionales (PRD §6)
| ID | Descripción | Cobertura | Notas |
|---|---|---|---|
| RF-01 | Generar facturas automáticamente desde eventos de negocio | ❌ | Fase 2 — requiere Jira/BUK como triggers |
| RF-02 | Soporte multimoneda USD/EUR/MXN | ⚠️ | MXN + USD en MVP, EUR en Fase 2 |
| RF-03 | Integración con sistemas existentes (BUK / nómina) | ❌ | BUK no expone API; Fase 2 |
| RF-04 | Registrar pagos automáticamente desde fuentes bancarias | ⚠️ | Automático vía Stripe; bancos vía PDF + conciliación |
| RF-05 | Asociar pagos a facturas | ✅ | Fase 2 |
| RF-06 | Identificar pagos parciales y completos | ✅ | Fase 2 |
| RF-07 | Conciliar automáticamente transacciones bancarias | ✅ | Fase 3 |
| RF-08 | Detectar discrepancias | ✅ | Fase 3 |
| RF-09 | Generar reportes de conciliación | ✅ | Fase 3 + 4 |
| RF-10 | Generar asientos contables automáticos | ❌ | Fase 2 (depende API BIND) |
| RF-11 | Integración con sistema contable | ⚠️ | Vía export en MVP |
| RF-12 | Dashboard financiero en tiempo real | ✅ | Fase 2 |
| RF-13 | Alertas automáticas configurables | ✅ | Fases 2-3 |
| RF-14 | Reportes exportables | ✅ | Fase 4 |
A.3 Requerimientos no funcionales (PRD §7)
| ID | Descripción | Cobertura | Notas |
|---|---|---|---|
| RNF-01 | Arquitectura modular y escalable | ✅ | Multi-tenancy en schema (tenant_id + RLS) desde día 1 |
| RNF-02 | Alta disponibilidad | ⚠️ | MVP single-region en Azure; HA real (multi-region, failover) → Fase 2 |
| RNF-03 | Seguridad de datos financieros | ✅ | Secretos cifrados, RBAC, audit log universal, hardening final en Fase 4 |
| RNF-04 | Cumplimiento fiscal (México y Texas) | ⚠️ | Tax estándar en MVP; compliance avanzado Texas → Fase 2 |
| RNF-05 | Integración con APIs externas | ✅ | Stripe, Claude API, DOF para TC |
| RNF-06 | Trazabilidad completa de operaciones | ✅ | Audit log universal desde Fase 1 |
A.4 Adicionales fuera del PRD oficial, incluidos en el MVP
Estas funcionalidades surgieron durante la llamada con el equipo directivo y se sumaron al alcance:
| Funcionalidad | Justificación | Fase |
|---|---|---|
| Pago con link Stripe (Checkout, tarjeta + SPEI) | Canal moderno de cobro sin depender del banco del cliente; webhook marca factura pagada automáticamente | Fase 2 |
| Parsing de PDFs bancarios con Claude API | Decisión técnica frente a parser hardcodeado por banco: los formatos cambian con frecuencia; salida estructurada robusta + validación contra totales | Fase 3 |
A.5 Diferidos a Fase 2 — resumen ejecutivo
Lo que no entra en las 6 semanas, agrupado por causa raíz:
Bloqueado por terceros (APIs no disponibles hoy):
- Generación automática de facturas desde eventos (Jira → BUK → Factura)
- Asientos contables automáticos contra BIND
- Integración bancaria en vivo (Belvo MX / Plaid / OCR IBC)
- Integración con BUK (nómina, contratos, freelancers)
- Integración con Jira (horas trabajadas → input facturación)
Decisión de alcance (priorizado fuera del MVP):
- EUR (no hay clientes europeos activos hoy)
- Cash-flow proyectado 30/60/90
- Detección avanzada de anomalías (z-score, vendor nuevo, horarios atípicos)
- Domiciliación / pagos recurrentes vía Stripe Subscriptions
- Portal de cliente self-service
- App móvil para tickets físicos
- Multi-tenancy comercial con onboarding self-service
- Compliance avanzado Texas (más allá de tax estándar)
A.6 Criterios de éxito del PRD (§13) y cómo se miden en MVP
| Criterio PRD | Cubierto | Cómo se mide en el MVP |
|---|---|---|
| Reducción de errores manuales ≥ 70% | ✅ | Línea base levantada en Fase 0; comparación al cierre del MVP sobre conciliación + cobranza |
| Disminución del tiempo de conciliación ≥ 60% | ✅ | Tiempo de conciliación pre-MVP (manual) vs. post-MVP (PDF + Claude API + cola humana) |
| Visibilidad en tiempo real | ✅ | Dashboard v1 entregado en Fase 2 |
| MVP funcional en ≤ 6 semanas | ✅ | Alcance comprometido y soft cap por fase |