Alternatives to SAP for order-to-cash automation are two categories, not one

There are. NetSuite, Microsoft Dynamics 365 F&SCM, Acumatica, Sage Intacct, Workday Financials, and Odoo are all credible O2C platforms in the right context. The honest filter is what shape your business has. NetSuite is the strongest mid-market all-rounder. Dynamics 365 F&SCM is the right call if you already run on Microsoft 365 and have manufacturing or distribution scale. Acumatica is the cheapest credible cloud ERP, with usage-based licensing that suits a sub-$500M revenue company. Sage Intacct shines on AR and revenue recognition for services and subscription, but is light on warehouse and order management. Workday Financials is the right fit when finance leadership already runs Workday HCM. Odoo is the open-source landing spot for SMBs leaving SAP B1, with the trade-off that the integration burden is yours.

For a mid-market company on SAP ECC or B1 moving to a credible alternative, the total project cost lands somewhere between $500K and $5M. License is usually the smallest line item. The bigger costs are implementation services (2x to 4x license), data migration and reconciliation, change management, and the parallel-run period where finance closes the books in two systems. Time to first wave live is typically 12 to 24 months, and the second wave (the modules left out of the first cut, like collections or revenue recognition) lands six to twelve months after that. None of those numbers are unique to SAP; they are the price of an ERP swap.

Because they target different parts of the same flow. Invoice-to-cash platforms (HighRadius, Sidetrade, Serrala, Kolleno) are themselves a kind of overlay, and they are excellent at the API-shaped parts: cash application from a bank file, dunning automation against an open AR table, deductions and disputes orchestrated through a portal. They struggle at the parts where humans still have to drive a screen because the data is not yet in the AR table or the decision is judgment-based. Sales-order entry from a customer-attached PDF, partial-wire allocation when the bank file does not auto-match, dunning review where the controller is suppressing customers and pushing levels by hand, credit-hold release as a judgment call. A desktop-level overlay drives those screens. The two layers are not in competition; they cover different surfaces of O2C.

Mediar fits the screen-shaped 30 to 50 percent of an O2C flow that no ERP swap removes. It records a workflow once, then drives the SAP shell or whichever ERP client by Windows accessibility APIs (the same surface a screen reader uses), so it works on legacy desktop systems that have no clean web service: SAP GUI, Oracle EBS, mainframes, JackHenry, Fiserv, FIS, Epic, Cerner. It does not fit the steady, API-shaped parts of O2C; the standard customer invoice on the happy path, the ATP check, the delivery confirmation from a 3PL feed are better served by the ERP's own web services or by a HighRadius-style platform layered on the AR table. It also does not fit a one-time bulk migration of 40,000 customer records; that is what data-migration cockpits are for.

The Mediar runtime ties recordings to the accessibility surface, not to pixel coordinates. Before two captured DOM trees are compared, a function called remove_volatile_dom_attributes (in apps/desktop/src-tauri/src/dom_tree_diff.rs in the open-source desktop agent) walks the JSON and drops every x, y, width, and height field, plus the value attribute on input elements. What is left to compare is role, name, automation IDs, and tab order, all of which the vendor maintains across releases because screen readers depend on them. A release that moves a field down a row produces no diff; the recorder does not see it. A release that actually renames a field shows up as a real change at the recording side, which is the place to fix it.

The executor classifies a connection reset, a 503, a 504, or a generic timeout as Infrastructure and retries with backoff. The default schedule from RetryConfig::default in crates/executor/src/config/retry.rs is initial_delay_secs 30, max_delay_secs 600, backoff_multiplier 2.0, and max_infrastructure_retries 3. So a session that drops for 90 seconds is invisible: the queue waits 30s, 60s, 120s, and continues. Anything the ERP itself rejects (validation failed, posting period closed, duplicate, permission denied) is classified as WorkflowLogic and never retried. Hammering the screen would not change the answer. Anything novel is classified as Unknown and stops the run for an operator ack.

Frequently, yes. If the SAP install is doing its job for the steady parts of O2C and the pain is concentrated in the human-decision screens (PDF sales orders piling up, AR Tuesdays burning four hours on partial-wire allocation, the dunning monitor reviewed by hand every week), then an ERP migration is a $500K-$5M answer to a problem an overlay solves in days. The migration also resets the team's accumulated tenant knowledge to zero. The honest test is whether the steady-state ERP work is broken (in which case migration may be justified) or whether the labor is concentrated in a small number of screens (in which case the overlay is cheaper, faster, and reversible).

UiPath and Power Automate Desktop are the incumbents in this space and they will solve the same shape of problem in many cases. The trade-off is cost and time-to-production. UiPath enterprise lands at roughly $100K minimum for a working pilot and assumes certified developers building studios, with a tail of selector maintenance every time the vendor reships the screen. Power Automate Desktop is cheaper but the recording engine is fragile against ERP shells like SAP GUI, Oracle EBS, and mainframe terminals, where the published llms.txt notes Power Automate Desktop tends to fall over. Mediar's stake against both is the accessibility-API approach: 20% of UiPath's cost, days instead of months to first production workflow, and recordings that survive the layout reshuffles because the diff strips the volatile attributes.

Three questions. (1) Is the steady, API-shaped O2C work broken on SAP, or is it actually fine and the labor is concentrated in a few screens? If the answer is 'a few screens', start with an overlay and revisit ERP scope after the screen labor is gone. (2) Are there strategic reasons to leave SAP that go beyond O2C automation: pricing, vendor relationship, M&A integration, a CFO mandate? If yes, the overlay is a tactical fix and the ERP migration is the strategic answer; you may end up doing both, with the overlay buying time. (3) Is the team big enough to absorb a 12 to 24 month parallel project? Mid-market finance teams running lean usually answer no, which pushes the order of operations to overlay first.

The Mediar Terminator SDK and the desktop agent are open source under MIT at github.com/mediar-ai/terminator. The volatile-attribute stripping is in apps/desktop/src-tauri/src/dom_tree_diff.rs. The retry classifier and backoff schedule are in crates/executor/src/config/retry.rs. The recording-driven workflow shape (a typed input schema, MCP tool steps, deterministic execution) is what survives the most frequent ERP release notes. Other overlay vendors do not publish their runtime; the open-source posture is what makes the surviving-a-release argument checkable.