AP automation cuts clerks, but only half of them. Here is which half, and why the other half still has a job.

Two AP clerk jobs exist, and the answer is different for each. The first is the digital-invoice approval clerk: receives PDF invoices in email, drops them into Bill.com or Stampli or Tipalti or Ramp Bill Pay or Coupa, codes the GL line, routes for approval, and pushes the result via API into NetSuite, QuickBooks Online, or Sage Intacct. That clerk is being cut. Every API-driven AP automation product on the market cuts that role, with documented headcount reductions in the 60 to 80 percent range. The second is the desktop AP clerk: takes the already-approved invoice and types it, line by line, into SAP Business One, Oracle EBS, JD Edwards, Jack Henry, Fiserv Premier, FIS IBS, NetSuite Desktop, QuickBooks Desktop, or a mainframe terminal. That clerk is still there, because those systems do not publish the kind of API surface a SaaS AP vendor can integrate against. Cutting that second clerk requires a different kind of agent: one that drives the GUI through Microsoft UI Automation rather than through a REST endpoint.

Because the SaaS AP architecture is API-out, and the legacy desktop architecture is API-absent. Bill.com integrates with NetSuite, QuickBooks Online, Xero, Sage Intacct, and Microsoft Dynamics 365 Business Central; these are cloud or modern accounting products with REST or SOAP surfaces. SAP Business One is a Windows desktop ERP whose primary interface is a thick client (the SAP B1 client) and whose published APIs (the DI Server, Service Layer, B1if) require a server-side install and a specific licensing tier that smaller B1 customers usually do not buy. Oracle EBS R12 has Oracle Integration Cloud and SOA Suite, but most line workers are using Oracle Forms screens that the SaaS AP vendor never integrates with. Jack Henry SilverLake, Fiserv Premier, and FIS IBS are core banking systems that ship with vendor-controlled integration partners and run-book paperwork, not a tenant-installable webhook. The SaaS AP product cannot ship a connector for a system whose vendor either charges five figures for the integration license or does not publish an integration surface at all.

Yes, and the headcount is bigger than the AP-automation marketing suggests. The Bureau of Labor Statistics still tracks tens of thousands of accounts payable and bookkeeping clerks whose primary tool is a Windows desktop ERP, not a SaaS AP product. The AvidXchange 2025 'AP Pros Face Growing Layoff Concerns' survey found that the AP professionals who feel most exposed to layoffs are exactly the ones whose day is dominated by data entry into a desktop ERP, because their work is the most repetitive AND the most invisible to the SaaS automation wave. They survive because the SaaS wave physically cannot reach them. They get cut when an accessibility-API agent does, which is a different vendor category from the one their CFO is comparing in the AP RFP.

Because the accessibility tree is universal where APIs are not. Every Windows GUI app, including the ones built in 1998, exposes its controls through Microsoft UI Automation, the same surface that screen readers consume. An accessibility-API agent reads the SAP B1 invoice form the way a screen reader does: 'edit field, label Vendor Code, value empty.' It writes the way a person does: focus the field, type the code, press Tab. It does not need a REST endpoint, an OAuth client, or a vendor-issued integration license. It does not need pixel matching, which is what makes vision-based RPA brittle when fonts or themes change. That is the exact difference between Mediar's surface and the surface that Bill.com and Stampli and Tipalti reach. Different surface, different boundary, different clerk job cut.

Mediar bills $0.75 per minute of agent runtime, plus a $10,000 turn-key program fee that converts to credits with a bonus, so it is effectively prepaid usage rather than a separate license. There is no per-seat fee, no per-bot fee, and no developer-certification fee. UiPath, Automation Anywhere, and Blue Prism quote on per-bot licensing, often in the $5,000 to $15,000 per unattended bot per year range, plus implementation services that for an enterprise SAP or Oracle project commonly land at $200,000 to $500,000 in the first year. We moved an LG-customer F&B chain from UiPath to Mediar; their CFO told the board they're now saving 70% on costs. That number is workflow-specific, not a generic claim, and it shows up in the section above.

Mid-market is where the math is cleanest. A regional bank on Jack Henry or Fiserv with an 8-week new-account onboarding window has the same workflow shape as a top-50 bank, but does not have the budget for a UiPath Center of Excellence. The same is true for a mid-market insurance carrier handling claims intake at 30 minutes per claim, or a community healthcare network on Epic or Cerner running patient intake by hand. Documented Mediar deployments at this size: bank onboarding from 8 weeks to 2 weeks, claims intake from 30 minutes to 2 minutes ($750K/year for one carrier), patient intake at $210K/year of recovered clerk time. The platform is SOC 2 Type II certified and HIPAA compliant, deployable on-prem or in a cloud environment the customer already owns.

No, and the conflation is what makes most coverage of this topic unhelpful. The AI-Overview headline is usually about LLM-driven document understanding (read a PDF, return JSON). That is genuinely better than the OCR-then-rules pipeline that AP teams have been running for fifteen years, and it is what Bill.com, Stampli, AppZen, and Vic.ai are shipping. It is also a different problem from getting structured data into a desktop ERP that does not have an API. LLM extraction plus a SaaS AP product cuts the digital approval clerk. LLM extraction plus an accessibility-API agent cuts the desktop posting clerk. The first half of the AP team and the second half are getting cut by different products built on different surfaces; the AI-Overview headline is reporting on the first.

Terminator is the open-source Windows-automation SDK Mediar publishes at github.com/mediar-ai/terminator. It is an MIT-licensed library for driving Windows UI Automation from Rust, Python, or Node, and it is the same primitive layer Mediar uses internally. Teams that want to extend Mediar with a custom workflow, or write their own agent against the same accessibility-API surface, work in Terminator. The Mediar product on top adds the workflow recorder, the no-code web app at app.mediar.ai/web, the SOC 2 / HIPAA control plane, the audit logs, the validation rules, the self-healing layer that recovers when a control's accessible name changes, and the runtime billing. The Terminator SDK is the open part; Mediar is the productized layer for teams that want the workflow recorded once and the runtime managed.