SAP cashier system, traced down to the one technical fact every other guide skips.

Almost always SAP Customer Checkout, SAP's point-of-sale product. It runs as a Java Swing application on a Windows checkout PC, handles sales, returns, vouchers, loyalty, and day-end closing, and posts transactions to SAP S/4HANA, SAP Business One, or SAP Business ByDesign through a backend connector. There are two shipping variants today: the on-premise Customer Checkout 2.0, which is the long-running release, and Customer Checkout cloud edition, announced in July 2025 as the SaaS replacement. A small fraction of searches are about SAM4s 'SAP-series' Android cash registers (SAP-530F, SAP-630F), which are unrelated hardware that happen to share the prefix in their model name.

Because most Windows automation tools (and most operating-system features) cannot read Swing widgets directly. Swing draws its UI inside the JVM with its own component model; from the outside, the Customer Checkout window looks like one undifferentiated bitmap. Oracle's Java Access Bridge is the official translation layer: it surfaces Swing's accessibility API to Windows so that screen readers, accessibility-API automation, and the OS itself can address each button, field, and grid cell as a normal UI Automation element. If Java Access Bridge is disabled on a checkout PC, anything that tries to read or type into Customer Checkout has to fall back to image matching, which is the brittle path. If it is enabled, the same UI Automation calls that work on SAP GUI, Excel, or Notepad work on Customer Checkout too.

On a 64-bit Windows machine with SAP Machine 17 installed, open an elevated command prompt, change directory to the JRE bin folder (typically %SAP_MACHINE_HOME%\bin), and run `jabswitch -enable`. That registers the system-wide bridge and writes the .accessibility.properties marker into the user profile. Restart Customer Checkout. To verify, open Microsoft's Inspect.exe (ships in the Windows SDK) or Accessibility Insights for Windows and hover over a Customer Checkout button: the role should resolve to Button or PushButton with an accessible name, not 'Pane' with no name. Oracle documents the same procedure for any 64-bit Java application; SAP does not override it.

The happy-path transactional flow is fine. Sales, payments, simple returns, gift cards, and day-end closing journals push to S/4HANA, Business One, or ByDesign through the configured backend connector with no human help. The work that still falls on the cashier or the store manager is the exception lane: returns where the original receipt is from a different store, manual coupon overrides, payment-terminal mismatches that have to be reconciled by hand at close, master-data gaps where the article scanned does not exist in the local cache yet, manager overrides that need to be re-keyed into a separate audit log, and the dance between the till count, the deposit slip, and the back-office workbook. Those exceptions are exactly the workflows that bring people to look for automation around 'SAP cashier system' in the first place.

Because the connector is point-to-point: it pushes finalized transactions from CCO to one backend ERP. It does not bridge the cashier PC to the loyalty portal, the e-commerce OMS, the manager's Excel workbook, the bank deposit web form, or the helpdesk ticketing system. Those are separate apps with their own UIs, often opened in a browser tab next to the Customer Checkout window. The exception workflows are the moments where the cashier alt-tabs between two or three of those, copies a number from one window, and types it into another. That is the work that does not have a SAP connector and never will, because the partner systems on the other side change too often.

Mediar runs as a Windows desktop agent on the same checkout PC. It reads the Customer Checkout UI through the Java Access Bridge bridge described above, plus the browser, Excel, and any other window the cashier touches, all through the same Windows UI Automation tree. A workflow is recorded by watching a real human do it once: open the loyalty portal, look up the card, paste the number into the CCO Customer field, finish the sale. The recording becomes a Zod-typed schema and a workflow file that runs unattended after that. We do not write a special Customer Checkout connector; we read the same accessibility tree the user already exposes by enabling Java Access Bridge.

Both, with a caveat. The on-prem 2.0 client is the Java Swing application described above and is the cleanest target. The cloud edition is the SaaS variant SAP announced in July 2025; the cashier UI for that edition is browser-based, which is a different accessibility tree (HTML / ARIA roles instead of Swing components) but the same UI Automation framework reads both. The exception workflows around the cashier PC, the loyalty portal, the Excel workbook, the deposit form, are identical in either case, so the work Mediar does on top sits in the same place. The Java Access Bridge step only matters for the Swing client.

It is the same thing your screen-reader users already need. Java Access Bridge ships with every supported 64-bit Java distribution, including SAP Machine. It exposes the Java accessibility API to Windows assistive technologies. Turning it on does not open a network port, does not change Customer Checkout's authentication model, and does not weaken the SAP backend connector. It does mean that any process running as the same logged-in user can read the Customer Checkout UI tree, which is also true of the existing Windows accessibility surface (Notepad, Excel, browser, SAP GUI). Customers running SOC 2 or HIPAA workloads typically allowlist the bridge in their endpoint policy and move on; we have not seen a hard 'no' on it from a security review.

Mediar is $0.75 per minute of runtime, with a $10K turn-key program fee that converts to credits. A typical exception workflow (look up loyalty, finish a return-with-receipt-from-other-store, post the day-end mismatch into the manager workbook) runs in 60 to 120 seconds, so under two dollars per execution. There is no per-seat license, no separate Customer Checkout add-on charge from SAP, and no specialized RPA developer requirement. The comparable UiPath pricing for Java automation against Customer Checkout, with attended-bot licenses on every cashier PC plus an orchestrator instance, comes in around five times that on the deployments we have seen, which is why the F&B chains we work with end up moving.

That is the worst case and the most honest place to acknowledge what automation cannot do. If the cashier has to make a judgment call (does this article look like ours? is this customer trustworthy?), the workflow has to wait at that step. Mediar handles this by pausing on the human-decision step in the recording: the desktop agent stops, the cashier types the article SKU into the override field, hits Enter, and the agent picks up from there. That is faster than scripting around it, and more honest than pretending an LLM can do retail loss prevention.