AI Invoice Processing and AP Automation

We integrate with SAP S/4HANA, SAP ECC, Oracle Fusion Cloud, Oracle EBS, Microsoft Dynamics 365 Finance, NetSuite, Workday Financials, and QuickBooks Online. Integration complexity depends on your specific configuration and which APIs your IT team has enabled. SAP S/4HANA with OData endpoints is the most common path. Oracle EBS often requires an intermediate integration platform. NetSuite uses SuiteTalk REST. We scope the specifics during discovery, including which fields are required on the A/P document, which tax determination method is in use, and how approval hierarchies resolve. Most integrations land in a 3-4 week window.

Claude Sonnet 4.5 handles format variability without per-vendor templates. For a new vendor with no prior processing history, the agent attempts extraction and routes the result to a human reviewer with the raw document side-by-side. The reviewer corrects any errors, and the agent writes that vendor's quirks (non-standard date format, line items in the footer instead of a table, tax as a percentage rather than a dollar amount) to a vendor-specific prompt fragment used on subsequent invoices. After 3-5 corrected invoices, most vendors process at 95%+ straight-through. There is no requirement for vendors to change their formats.

For invoices with valid PO references and no discrepancies, straight-through rates run 80-90% after 60 days of operation on a representative vendor mix. The remaining 10-20% involve genuine exceptions: price or quantity variances above tolerance, new vendors, invoices without PO references, or invoices where the vendor has changed their remit-to address. These are real exceptions that should involve human review, not system failures. We track straight-through rate weekly and work with AP leadership to identify systemic exception causes (a specific vendor with consistent tolerance issues, a cost center with stale POs) that can be addressed at the source rather than in AP.

Every invoice that scores below a configurable confidence threshold (typically 85%) routes to human review with the agent's best extraction pre-populated and the specific low-confidence fields highlighted. The reviewer either confirms or corrects. The correction writes back to the agent's memory for that vendor. The system never posts a decision it is not confident in. For a genuinely novel edge case, the first time it appears the agent flags it, a human resolves it, and the resolution informs future handling. The design assumes exceptions will always exist and builds the review path as a first-class workflow rather than an error condition.

Wrong can mean three things. First, an extraction error caught in validation: the invoice totals don't foot, a date is invalid, a PO number points to a closed PO. These never reach posting because the validation rules block them. Second, an extraction error that passes validation but is caught on approval: the approver rejects, the reasons are logged, and the vendor-specific prompt is updated. Third, an error that reaches posting: the system creates an audit entry that supports a reversing entry in the ERP and an alert to AP leadership. Across our deployments, type-three errors run under 0.3%, lower than the manual baseline they replace.

Every agent action writes an entry to an append-only Postgres log: invoice ID, timestamp, input payload, extracted fields, PO match result, GL coding decision, approver, posting document number, and a hash chain to prevent tampering. The log exports to CSV or straight to your audit tool (AuditBoard, TeamMate, Workiva) via scheduled push. For SOX-scoped controls we configure dual-control on any coding override above a threshold and produce a quarterly attestation report automatically. External auditors have access to the same log your internal team does. Most auditors we've worked with prefer this trail over manual paper documentation because it answers sampling questions in minutes.

Three things, in order of impact. First, vendor master cleanup: deduplicate vendor records, validate remit-to addresses, confirm tax IDs. The agent is only as good as this data. Second, 24 months of historical coded invoices as a training signal for GL coding patterns. We can pull this from your ERP directly if you can grant read access. Third, a documented tolerance matrix: what price variance is acceptable by category, what quantity variance, what approval bands per amount. Most AP teams have this informally; we formalize it. Budget 2-3 weeks for this prep work in parallel with technical integration. Skipping it doesn't break the system but it reduces straight-through rates by 15-25 points.

A focused deployment covering your top 50 vendors and one ERP entity runs 8-10 weeks from kickoff to first production invoice. Weeks 1-2 are discovery and data access. Weeks 3-5 build the extraction, matching, and coding pipeline on a dev environment using historical invoices. Weeks 6-7 run a shadow mode where the agent processes live invoices in parallel with the manual team, and accuracy is compared daily. Weeks 8-10 are cutover: the agent processes production invoices with tight monitoring. Full coverage across all vendors and entities typically takes another 8-12 weeks. We don't recommend a big-bang rollout. Phased cutover by vendor tier gives the team time to calibrate.