Plataforma de Cuentas por Pagar
Payables
Un flujo moderno de cuentas por pagar diseñado en torno al procesamiento real de facturas.
- Diseño de Producto · UX/UI · Ingeniería Frontend
- Desafío técnico (take-home)
- Next.js, React, TypeScript, Prisma, PostgreSQL, Tailwind CSS, Docker
Resumen
La mayoría de las demos de gestión de facturas se limitan a operaciones CRUD. Quise modelar el flujo real que siguen los equipos de finanzas al procesar facturas.
En lugar de partir de un formulario vacío, cada factura comienza con una factura subida, pasa por extracción OCR, verificación manual cuando hace falta, aprobaciones basadas en roles, programación de pago y finalmente confirmación de pago.
El proyecto combina pensamiento de producto, diseño UX y arquitectura frontend, manteniendo la implementación lo suficientemente modular como para reemplazar los servicios de demo por integraciones de producción.
El Problema
Los equipos de Cuentas por Pagar rara vez crean facturas manualmente.
El flujo real suele verse así:
- Recibir factura
- Extraer información
- Revisar datos faltantes
- Aprobar
- Programar pago
- Marcar como pagada
Muchas demos se saltan estos pasos y van directo a un formulario.
Quería que la experiencia se sintiera más cercana a un producto financiero real.
Objetivos
- Diseñar un flujo de facturación de punta a punta en lugar de una aplicación CRUD.
- Simular la extracción OCR manteniendo una arquitectura lista para producción.
- Soportar distintos roles de usuario con responsabilidades diferentes.
- Construir primitivas de UI reutilizables en lugar de componentes específicos de cada página.
- Mantener la lógica de negocio aislada de las cuestiones de infraestructura.
Flujo de trabajo
Subir factura
El flujo comienza con arrastrar y soltar.
En lugar de crear una factura vacía, los usuarios suben una factura.
Un servicio de OCR simulado extrae:
- Proveedor
- Número de factura
- Fechas
- Ítems de línea
- Monto
Tres plantillas de factura distintas simulan diferentes resultados de OCR.
Revisar información faltante
El OCR no es perfecto.
Una factura falla intencionalmente en detectar campos importantes.
En lugar de bloquear el flujo, la aplicación resalta la información faltante y permite completarla manualmente antes de enviarla a aprobación.
Esto modela cómo se comporta un software de AP en producción.
Revisión de factura
La página de Detalle de Factura coloca la factura original junto a la información extraída.
Para la demo, cada factura referencia un PDF simulado.
La arquitectura almacena un documentRef opaco, que permite reemplazar los PDFs simulados por archivos subidos reales con cambios mínimos en el código.
El documento sigue siendo la fuente de verdad mientras los usuarios verifican:
- Proveedor
- Número de factura
- Fechas
- Ítems de línea
- Totales
Flujo de aprobación multi-rol
La aplicación simula tres roles distintos.
AP Specialist
- Subir facturas
- Completar información faltante
- Enviar a aprobación
Manager
- Revisar facturas
- Aprobar
- Rechazar
- Solicitar cambios (con motivo obligatorio)
Finance
- Programar pagos
- Marcar facturas como pagadas
El dashboard cambia automáticamente según el rol seleccionado.
Historial de auditoría
Cada acción importante genera una entrada de actividad.
Ejemplos:
- Enviada
- Aprobada
- Rechazada
- Cambios solicitados
- Programada
- Pagada
Esto crea una línea de tiempo completa del ciclo de vida de la factura.
Decisiones de UX
Crear facturas manualmente no representa cómo funciona un software de AP real. El flujo de carga acerca mucho más la experiencia a producción.
La factura es el centro del proceso de revisión. La información extraída acompaña al documento, no al revés.
En lugar de mostrar un error, una extracción OCR incompleta pasa a formar parte del flujo. Esto genera una experiencia de revisión más realista.
Cada rol ve solo la información relevante para sus responsabilidades. Esto reduce la carga cognitiva mientras demuestra distintos flujos sobre el mismo conjunto de datos.
Arquitectura
Varias decisiones de arquitectura se tomaron a propósito para que la demo pudiera evolucionar hacia una implementación de producción.
Pipeline de carga
- Carga
- OCR simulado
- processInvoice()
- Factura en borrador
- Revisión
- Flujo de aprobación
Abstracción de documentos
Las facturas almacenan un documentRef opaco.
La aplicación lo resuelve a través de una única función.
Hoy apunta a PDFs simulados.
Mañana podría generar URLs firmadas de S3 sin cambiar ningún componente de UI.
Lógica de negocio compartida
Las reglas de negocio están centralizadas:
- Cálculos monetarios
- Mapeos de actividad
- Definiciones de campos faltantes
- Manejo reutilizable de errores en server actions
Esto evita lógica duplicada entre cliente y servidor.
Sistema de diseño
La UI está construida a partir de primitivas reutilizables:
- Button
- Card
- Dialog
- Badge
- Dropdown
- Tooltip
- SearchInput
- Toast
- VendorSelector
El objetivo fue la consistencia, no componentes específicos de cada página.
Aspectos técnicos destacados
- Next.js App Router
- React Server Components
- Server Actions
- Prisma ORM
- PostgreSQL
- TypeScript
- Docker
- Diseño responsivo
- Interacciones de teclado accesibles
- UI basada en roles
- Pipeline de OCR simulado
- Vista previa de factura embebida
Desafíos
Un desafío interesante fue lograr que la implementación simulada se sintiera realista sin acoplar la aplicación a los datos de demo.
En lugar de almacenar rutas de archivo directas, las facturas referencian documentos a través de un resolver. Se usó el mismo enfoque para la capa de OCR, permitiendo que servicios de producción reemplacen las implementaciones simuladas sin afectar el resto de la aplicación.
Otro desafío fue modelar un flujo de aprobación creíble manteniendo la UI lo suficientemente simple para un proyecto take-home.
Qué construiría después
- Integración real de OCR
- Almacenamiento de archivos en la nube
- Autenticación y autorización
- Notificaciones
- Operaciones masivas de facturas
- Paginación y filtrado del lado del servidor
- Políticas de aprobación avanzadas
Resultado
El resultado final es más que una aplicación CRUD.
Demuestra cómo el pensamiento de producto, las decisiones de UX y la arquitectura frontend trabajan juntos para modelar un flujo realista de Cuentas por Pagar, manteniéndose mantenible, escalable y lista para evolucionar hacia una implementación de producción.