Writing back into a system that has no usable API

When an automation project for a mid-market accounts-payable queue stalls, the post-mortem usually blames the model: the agent couldn't read the invoices well enough, the accuracy wasn't there, the vendor oversold. That diagnosis is almost always wrong, because the model is generally fine. What broke is the part nobody budgeted for: getting the answer back into the system of record. The business runs on QuickBooks, and the clerk posts a bill by clicking through three screens. Intuit does document ways for software to post the same bill, but each one is a separate integration that someone has to build, authorize and keep running. The integration surface is the bottleneck, not the intelligence, and that distinction explains why so much of this work dies after the demo.

What the RPA record shows

The robotic-process-automation wave of the last decade ran this experiment at scale, and it left a mixed record. EY's "Get ready for robots" reports seeing as many as thirty to fifty percent of initial RPA projects fail, and in Deloitte's 2017 global RPA survey, sixty-three percent of the thirty-two respondents who had already implemented RPA said implementation took longer than expected. Neither firm blames the integration surface for those numbers. EY writes that this "isn't a reflection of the technology" and traces the failures to ten planning and delivery mistakes, from treating RPA as an IT project to targeting the wrong processes, and Deloitte suggests the overruns came from organizations underestimating the time and cost of delivery. Integration does show up in Deloitte's findings: respondents who had implemented and scaled RPA ranked integration and flexibility third among their challenges, after process standardization and IT buy-in. It matters here because an RPA bot scripted against a screen or holding an authentication token is brittle by construction. When the UI it was recorded against changes, when the token expires, when a vendor ships a patch that moves a button, the bot keeps running and silently does the wrong thing, or it stops doing anything at all. The failure mode is quiet rather than loud: a finance team discovers three weeks later that nothing posted, which is precisely the kind of failure a controller cannot tolerate in a workflow that touches the ledger.

What writing to the system of record takes

QuickBooks is the canonical case because of its reach: Intuit's own fact sheet puts it at over seven million online paying customers in FY22. Intuit does document how software can post a bill. The QuickBooks Online Accounting API has a Bill create operation, and the QuickBooks Desktop SDK has BillAdd, which Intuit describes as providing the functionality of the Enter Bills form the clerk uses. Each one is an integration in its own right. A QuickBooks Online connection runs on access tokens that expire after an hour and refresh tokens that expire after a hundred days unless the app keeps renewing them, and once a refresh token lapses, a person has to authorize the app again. A Desktop integration has to run on the same machine as QuickBooks, or in some cases the same local network. Someone has to build that connection, keep its authorization alive, and fix it when it breaks, and that is the part nobody budgeted for. Where a system offers no documented path at all, the connector-and-bot approach covers the gap with a UI script that inherits every fragility of the screen it imitates, and you end up depending on a contract the vendor never agreed to.

Act at the interface a human already uses

The engineering move that avoids both the separate integration and the brittle script is to work at the desktop the clerk already uses. The interface a human operates is one the vendor has to keep working, because their own customers depend on it; it changes slowly, it's documented for people, and when it does change, the change is visible rather than silent. An agent that reads the same screens, fills the same fields, and posts through the same workflow a clerk would is acting at the layer the business actually runs on, which is the system of action sitting on top of the system of record. This isn't screen-scraping with extra steps so much as the recognition that, for a system with no usable API, the supported and durable surface is the human one, and the right place to build is where the work already happens rather than around it.

The accounts-payable queue, walked through

Take the AP queue concretely. An invoice arrives, and the job is a three-way match: reconcile the invoice against the purchase order and the receiving record, confirm the quantities and prices line up, and post the approved bill into QuickBooks. The capture and extraction tier handles the clean cases, and a rules-and-OCR pipeline goes only as far as its templates, because a fixed template only works on layouts it has already seen. The remainder is the long tail of layout variance, the vendor who reformats their invoice, the line items that wrap, the handwritten note in the margin, and that's where a model plus a human earns its place, pushing straight-through processing into the cases the templates never reached. The match itself is logic, and current systems do it reliably. The genuinely hard part, the part where these projects historically die, is the last step: taking the posted result and writing it back into QuickBooks through the same screens a clerk uses, reliably, every time, without a token that expires or a recorded macro that breaks when the layout shifts.

This is the production gap, not a model gap

What this reframes is where the difficulty in enterprise AI actually lives. The popular story is that the models aren't good enough yet, but in a three-way-match workflow the reasoning is well within reach of current systems, and getting the read side to production accuracy on variable documents is the long-tail problem that capture-plus-model handles. The write side is where the eighty-to-ninety-nine-percent production gap opens up, and it opens up at the integration surface rather than in the model. A reasonable counter is that vendor APIs are improving and the no-connector argument will date itself as the supported surfaces widen. There's something to that for the largest platforms, but it misreads the mid-market: the systems these companies run on are old, customized, partially supported, and frequently a version or two behind, so the API coverage gap is widest exactly for the workflows worth automating. Even where an API exists, it tends to cover the simple writes and stop short of the exception handling that is most of the actual job, so betting the reliability of a month-end close on a partial API is a bet the discovery work will usually advise against. The interface a human uses is the one you can count on, and building there is what separates a system that posts the bill every time from a bot that quietly stopped three weeks ago.