Data entry automation has two halves. Almost every guide stops at the first one.

The two halves, drawn honestly

Every guide we read for the research on this page used some variant of the same diagram. Document on the left, OCR or AI in the middle, a green check on the right. The check is doing a lot of work. Here is the same diagram with the step that the green check actually stands in for, named.

The first three boxes are commodity. There are five honest options for any of them, more if you count the free ones. The fourth box is where every project we touch has stalled at least once. The destination is a Windows desktop app. There is no public API. There is a person sitting in front of it whose calendar will tell you that they spend three hours a day typing the JSON from the third box into the fourth box.

What does an entered field actually look like?

Most coverage of data entry automation talks about the destination step in marketing terms (“writes back to your system of record”) without ever showing what the bot is doing at the field level. There are two common shapes. One of them is what most legacy RPA stacks shipped through 2024. The other is what an accessibility-tree-bound recorder emits today. Switch the tabs to compare.

// What most "automate this form" stacks emit:
//   image template-match + XPath fallback
{
  "step": "data_entry",
  "image_template": "company_code_field@1920x1080.png",
  "image_threshold": 0.92,
  "xpath_fallback":
    "/html/body/div[3]/form/div[7]/div/div[2]/input[1]",
  "value": "1000"
}

// Two ways this dies:
//  1. The screen renders at 2560x1440 on the Citrix farm and the
//     template miss-matches by 4 pixels.
//  2. The vendor ships a UI patch and the XPath now points at
//     a hidden div that no longer accepts input. The bot types
//     into nothing, the script reports success, the journal is
//     never posted, and you find out at month-close.

The right-hand version is not theoretical. The struct is in the open-source workflow recorder at terminator/crates/terminator-workflow-recorder/src/events.rs, as a Rust struct named TextInputCompletedEvent with the eight fields you saw above. The conversion to a runtime MCP step lives in mcp_converter.rs, which builds the type_into_element step with clear_before_typing set true and a 5000ms timeout. Anyone can clone the repo and read the lines for themselves.

Why the input method field exists

One detail in that struct is worth its own paragraph. The recorder does not just save what was typed. It saves how it was typed. The input_method field is one of five values:

• Typed — character-by-character keystrokes. The runtime can replay this with a per-character delay so apps with debounced input handlers (SAP GUI, some Java Swing forms) see the same event stream they expect.
• Pasted — a large block arrived quickly. The runtime should paste, not type, so a 240-character chart-note does not take 30 seconds.
• AutoFilled — the field was completed by the app itself (a downstream value derived from a prior field). The runtime should skip it, because re-entering it can clobber the derivation.
• Suggestion — the user took an autocomplete choice. The runtime needs to type the prefix and then arrow-down into the dropdown, not paste the final string.
• Mixed — some combination, treated conservatively.

The top-ranking guides on data entry automation do not mention any of this, because most of them describe the extract step and treat the destination as an HTTP POST. Once you accept that the destination is a real Windows process and not a JSON endpoint, the shape of an entered field has to carry this much detail. Otherwise the playback either takes too long, crashes the destination, or looks correct and silently corrupts a derived value.

What this still does not solve

A page that only describes the easy cases is a brochure. Three honest limits.

1. Some destination apps render their fields as images of text with no accessibility tree. A small set of niche field-service tools and a few industrial HMIs are built this way. On those, the runtime falls back to image-based locators that are slower and less reliable. We have not seen this on any common ERP, EHR, banking core, or mainframe terminal emulator we have shipped against, but it does exist.
2. If the destination form changes shape (new required field, new tab, different navigation path), the recording has to be redone. The schema is fixed at recording time. Self-healing covers label and layout drift, not new fields the recording never saw.
3. Handwriting, multi-language carbon copies, and severely degraded scans still need a human review at the extract step. The enter step does not improve recognition quality of the input documents.

Within those limits, the round trip is what most ops, finance, claims, and intake teams are actually trying to buy when they search for data entry automation. They are not trying to buy a smarter extractor. They have an extractor. They are trying to get the values into the form without a human paste step.

Frequently asked questions