Document automation tools split into four layers. Most lists fuse them.

Software that handles part or all of a document's journey from arrival to settled state in a system of record. The category covers four layers in practice: capture (scanner, email, upload), extract (OCR or IDP turns the PDF into JSON), route and sign (approval, e-signature, archive), and post (the parsed data is written into the system of record). Most public listicles call any of the four 'document automation,' which is true at the marketing level and unhelpful at the buying level.

Because nothing in the market does all four well, and the layer you have a bottleneck at decides which vendor is even relevant. A team where the destination is NetSuite or Coupa (clean APIs) has no posting problem and an IDP plus a route tool is the whole stack. A team where the destination is SAP GUI, Jack Henry, or Epic has the IDP figured out and a posting problem worth six figures a year. Lists that fuse the layers will recommend an IDP for a posting bottleneck or an RPA platform for a parsing bottleneck, and the buyer wastes a cycle.

Pick by the layer where you have actual minutes-of-human-work to remove. Capture bottleneck (scanning, classification): ABBYY, Hyland, DocuWare, OpenText. Extraction bottleneck (parsing): Rossum, Hypatos, Ocrolus, Google Document AI, AWS Textract, Azure Document Intelligence, Tungsten. Route or sign bottleneck: DocuSign, PandaDoc, Adobe Sign, Conga, Nintex, Laserfiche. Posting bottleneck where the destination is legacy desktop: UiPath, Automation Anywhere, Power Automate Desktop, Blue Prism, Mediar. The right answer is usually two tools, one at the bottleneck layer and one that picks up the rest.

They list ten vendors side by side without naming which layer each one operates at, so a buyer with a posting bottleneck reads about Rossum's classification accuracy and a buyer with an extraction bottleneck reads about UiPath's enterprise licensing. The layer split is rarely visible in the chart. The honest version is a layered category map first, then a tool comparison inside the layer that matches the bottleneck.

Three reasons. First, it is unglamorous: typing into a 1990s WinForms or Hyperspace screen is not what most marketing wants to lead with. Second, the modern SaaS world (NetSuite, Workday, Bill.com) does have APIs, so the posting layer collapses into one HTTP call and stops being a category. Third, the buyers with the posting problem are concentrated in F&B on SAP B1, banking on Jack Henry and Fiserv, healthcare on Epic and Cerner, and insurance on legacy policy admin systems. They are not the audience writing the public tools roundups. The result is a category gap.

In apps/desktop/src-tauri/src/recording_processor.rs the function is_meaningful_event_type returns true for exactly six event types: button_click, browser_click, text_input_completed, browser_tab_navigation, application_switch, and file_opened. Opening a PDF lands as a labeled boundary in the same stream as the destination clicks and types. The labeling stage then waits on check_labeling_gate, which requires analyses for indices [N-5, N+5] to be complete before labeling event N. That eleven-event window is what lets the synthesizer label 'PDF open, then type vendor code into SAP B1 vendor master, then save' as one step, instead of three unrelated ones. No other layer-4 tool surfaces that structure.

Yes, for any document that needs structured extraction. The honest pattern is to keep whichever IDP your team already trusts (Rossum, Hypatos, Ocrolus, Adobe Acrobat AI, Google Document AI, AWS Textract, Azure Document Intelligence, Tungsten) and pair it with a layer-4 tool for posting. The two layers are complementary. Mediar specifically does not compete on extraction accuracy; the recorder picks the workflow up at the point where the operator opens the parsed file or the IDP's review screen and continues into the destination.

When the destination is a modern SaaS application with a public write API. Posting through a UI is slower and less reliable than a direct API call for any flow that lands in NetSuite, Workday, Salesforce (current), Bill.com, Coupa, or HubSpot. A team where every destination is in that list does not need a layer-4 tool at all. The posting category is sized for legacy Windows desktop systems where SAP GUI, Oracle EBS, Epic, Cerner, Jack Henry, Fiserv, and FIS live, because those vendors do not publish write APIs for many of the screens the operators use every day.

Mediar's executor is $0.75 per minute of execution drawn against a $10,000 turn-key program fee that converts to credits. A three-minute SAP B1 invoice posting costs $2.25 of meter time. The honest comparison is to the line item that gets removed: an AP clerk hour, a UiPath maintenance contract for the workflow, or the offshore-keying line on a BPO invoice. Documented numbers from real deployments include 70 percent cost reduction at an LG-customer F&B chain that moved from UiPath, $750,000 a year saved on insurance claims intake at one mid-market carrier, and $210,000 a year on patient intake at a regional healthcare provider.

The document workflow automation software guide is angled at the recording loop, focusing on file_opened as a meaningful event and how the recorder treats it. This guide is the wider category map: it places the recording loop inside the broader four-layer landscape, lists the named tools in each layer, and explains how to pick by bottleneck. Read this one first if you are scoping a buying decision and the workflow page next if you have already narrowed to the posting layer.

The Terminator SDK that powers the runtime is published at github.com/mediar-ai/terminator. The selector primitives, the locator with timeout-and-fallback semantics, and the workflow executor are all in that repo. The hosted product UI on top (no-code recorder, workflow synthesis pipeline, cloud executor) is closed source. The split is the honest answer for a security review that needs to inspect the part of the stack touching the OS accessibility tree; the OS-facing part is open.