Part of: AI-native finance operations: what it actually means
The conversation about AI document extraction usually ends at accuracy. The model hits ninety-four percent. Everyone agrees that is impressive. The pilot then dies, because nobody figured out what to do with the other six percent.
A healthcare receivables operation I led ran roughly fifty thousand invoices per month — payor remittances arriving as 6,000+ pages of mixed-format documents that had to land cleanly in Sage Intacct as receivables invoices, payments, and adjustments tied to specific customer and payor records. The system shipped. Here is the architecture that made it production-grade.
Phase A — Discovery and proof of concept. Six months. Requirements gathering with finance and operations stakeholders. Workflow mapping for receivables, revenue recognition, and reporting. The deliverable was not a model. The deliverable was a project blueprint and an initial connector prototype pulling charges and payments into a local SQL replica.
Phase B — Posting engine. Five months. Custom API integration that transformed practice management charges, payments, and adjustments into Sage Intacct receivables objects. Error handling, idempotency, and reconciliation routines built in from day one. Sandbox runs against 465,000+ historical transactions. The model handled the extraction. The architecture handled everything else.
Phase C — Sandbox deployment and error remediation. Four months. Duplicate deposit handling. Cash management setup. Receivables adjustment logic. Creation of reconciliation reports and an error taxonomy for API failures. This is the phase that most pilots skip — and exactly where production failure becomes inevitable.
Phase D — Analytics enablement and AWS RDS architecture. Four months. Design and deployment of an operational data store on AWS RDS with ODBC connectivity to the source system. Revenue recognition support and multi-entity considerations. The data warehouse and integration runtime lived on the client's infrastructure, not the vendor's.
Phase E — Stabilization, full rebuild, and handover. Five months. Database rebuild on a sandbox release. Final validation. Documentation package and source code handed to the client's incoming CTO.
Total elapsed time before production: twenty-four months. Total time the model itself was being tuned: roughly six weeks. Everything else was architecture, exception handling, reconciliation logic, and the audit-survivable scaffolding around the model.
The result: roughly thirty percent improvement in the collections cycle and a system that runs without manual reintervention.
If a vendor is telling you a similar system can ship in ninety days, they are quoting the model build, not the production deployment. The two timelines have almost nothing to do with each other.
Filed under
