Outcome at a glance
- About 4 million financial and operational records
- Four restaurant locations with live sales data
- Three production integrations: Restaurant365, PAR, and DeliverSense
- 55 backend endpoints and 22 application pages
- Up to $40,000 in discrepancies identified and corrected in time
Problem
A multi-location restaurant operator had financial and operating data spread across accounting, point-of-sale, labor, and third-party delivery systems. Each source used different identifiers and reporting rules. Spreadsheet reconciliation took time, delayed decisions, and made mismatches hard to trace back to the source.
The useful question was larger than “what were sales yesterday?” Ownership needed one system that could explain where a number came from, compare it with the other systems, and surface records that required attention.
Approach
I built a production financial-operations platform in TypeScript and Next.js. Scheduled source adapters ingest Restaurant365, PAR, and DeliverSense data, normalize it into PostgreSQL, and preserve source identifiers for reconciliation.
The application combines financial views with investigation tools. Operators can move from an aggregate result to the location, date, source, and records behind it. This made the dashboard useful for correcting data, instead of becoming another report that repeated the same error.
Architecture
The platform runs on AWS. EventBridge starts scheduled ingestion jobs, ECS Fargate runs the application and workers, and RDS PostgreSQL stores normalized and source-level data. CloudFront serves the web application. Secrets Manager and CloudWatch handle credentials and operational visibility.
Authentication uses signed sessions, Argon2 password hashing, and role-based access controls. The public case study omits customer records, internal identifiers, and source-specific business rules.
Data-quality design
Each integration has its own adapter and normalization boundary. The pipeline stores a source key, location, business date, and ingestion timestamp before a record enters shared reporting logic. That structure supports three important checks:
- Completeness: Did every expected location and date arrive?
- Consistency: Do sales, tenders, labor, and deposits reconcile across systems?
- Validity: Are rates, durations, amounts, and mappings operationally possible?
The same method exposed explicit zero-rate labor records and impossible shift durations during a historical audit. I kept invalid records separate from recoverable missing-rate records so the correction estimate stayed reproducible.
Product surface
The verified application contains 55 backend endpoints and 22 pages spanning sales, cash flow, labor, reconciliation, data quality, integrations, and administration. The product supports four live restaurant locations and about 4 million records across roughly 18 months of operating history.
The most important result came from reconciliation: the system identified up to $40,000 in discrepancies that the business corrected before they became permanent losses.
What moved, what constrained it, and what trade-offs stayed visible.
Operational outcome, the limits around it, and the practical decisions that shaped the work.
Unified about 4 million records from three live production sources across four restaurant locations. Reconciliation and data-quality analysis identified up to $40,000 in discrepancies that the business corrected in time.
Financial and payroll data required strict access control, source traceability, and public NDA-safe presentation. Each external system used different identifiers and update schedules.
Used scheduled ingestion because the source systems expose batch-oriented data. Kept one deployable application with separate adapter and domain boundaries so a small operator could maintain it without distributed-system overhead.
Links
- Architecture and selected implementation details are available on request