SAP Business One order-to-cash automation: the HANA versus SQL Server fork most guides skip.

The thesis, plainly

The most common shape of a B1 O2C automation project is to draw the flow as a sequence of arrows (Quotation, Order, Delivery, Invoice, Payment) and then ask a developer to wire whichever integration the internet says to use. If your team has already done that on a friend's S/4HANA tenant, you reach for BAPIs. If you have read the official B1 Service Layer docs, you reach for REST. Both lead to a stall when the actual customer's database turns out to be Microsoft SQL Server.

The shape that ships is to score every step in the cycle as Service-Layer-only, DI-API-only, mixed, or UI-only, then build the API portion against whatever the tenant's backend supports and drive the rest with a recorder against the desktop client. The recorder is the only path that runs unchanged across HANA and SQL Server, because it talks to the same SAP Business One.exe Win32 window in either case.

The rest of this page is that score, then the parts of the cycle where the score is non-obvious (the Matrix line-item grid, the A/R Invoice posting period rules, and the Incoming Payment matching step), then a recorded workflow you can run today.

The seam map: five steps, two backends

Each row is one step in the O2C cycle. The HANA and SQL Server columns score the cleanest available API path on each backend. The UI Automation column is the same for both because it talks to the desktop client, not the database.

The teal column is the only one that ships unchanged across both backends. It is also the only one that handles the Incoming Payment matching step, because that step is a judgment call (which open invoices does this wire most likely cover) that no API resolves on its behalf.

Why Service Layer is HANA-only, and what changes if you have it

Service Layer is a Linux-side service that talks to the B1 HANA schema using HANA-native SQL and column-store features. The standard B1 on Microsoft SQL Server installation does not include it; the SAP Help Portal Service Layer configuration page lists HANA as the prerequisite. If a partner says they have Service Layer working against a SQL Server tenant, double-check what they actually mean, because in most cases it is a third-party REST proxy in front of DI API and not the SAP-shipped Service Layer.

On HANA, Service Layer makes the steady steps (Quotation, Order, Delivery on a clean B2B order, A/R Invoice on a clean order, posting a pre-allocated Incoming Payment) cheap. Each one is an HTTP POST with a JSON body. The endpoints are well-shaped. Throughput is better than DI API because Service Layer pools sessions across multiple workers.

What does not change: the screens where a human still decides something. The recorder still owns sales order entry from a customer-emailed PDF, the manual side of Incoming Payment allocation, credit hold release on customers near their limit, and anything in an ISV add-on. Service Layer answers fewer than half the steps for most teams; it answers the cheap half.

The shape that ships across both backends

Below is a simplified version of one recorded workflow. It walks a PDF-extracted sales order through the four-document chain using the Copy To pattern a B1 operator already uses. The same file runs on a HANA tenant, a SQL Server tenant, a Citrix-hosted client, or a dedicated Windows VM. The runtime targets the SAP Business One.exe process via Microsoft UI Automation. Nothing in the workflow file knows or cares what database is behind the screen.

Each commented step resolves to one or two MCP tool calls against the B1 UIA tree. Locators target Name plus Role on each element (name:Customer|role:Edit), not pixel coordinates. The runtime strips x, y, width, height, and the captured value attribute before diffing two trees, so a B1 patch level that nudges the layout does not produce a workflow diff. That stripping is in the open-source desktop agent at apps/desktop/src-tauri/src/dom_tree_diff.rs in github.com/mediar-ai/terminator.

The Matrix grid: where line-item entry actually breaks

The Matrix is the line-item editor on every B1 sales document. It looks like a spreadsheet and the temptation is to treat it like one. The accessibility tree exposes it as a UIA Table with rows and columns, which is the right substrate for automation. The hard parts are not the substrate; they are three specific behaviors a recorded workflow has to handle explicitly.

First, the Item No. cell triggers a price-list lookup that fires asynchronously. Typing the next field before the lookup completes means the unit price you see in the recording is not the unit price the document is posted with. The recorder waits on a property change on the row's UnitPrice Edit element rather than a fixed sleep, so the wait scales with how loaded the price list is.

Second, batch-managed and serial-managed items pop a modal Batch Selection or Serial Number Selection window when you set the quantity. That modal has to be drained inside the same step that sets the quantity, or the row's commit attempts to read uninitialized batch state and fails with a generic validation error. The recorder treats the quantity entry and the batch selection as one atomic step, not two.

Third, B1 keeps a trailing empty row in the Matrix until you click outside the grid. A naive recorder that reads the row count mid-entry will either over-count or attempt to address a row that does not yet exist. The fix is to commit the grid by clicking the Customer field after the last row, then capture the row count.

A/R Invoice posting and the period-status trap

The A/R Invoice is the first step in the chain that hits the general ledger, and it is the first step where B1 will refuse to post even though every field on the form is correct. The most common refusal is a posting period that is closed or locked. The posting period is set per Document Series under Administration > System Initialization > Document Numbering, and it is enforced per posting transaction.

The recorder has to capture the modal that B1 raises (Period is locked for posting, document cannot be added) and route it to the right escalation. A practical pattern is to classify it as a WorkflowLogic error in the executor: do not retry, do not call the analyzer, hold the row in the queue with a clear reason, and let the AR clerk decide whether to re-open the period or move the posting date. The retry classifier in the open-source agent is in crates/executor/src/config/retry.rs and the WorkflowLogic class is where this case lands.

The same modal can also fire for a missing chart-of-accounts mapping on a new item, a customer over its credit limit (when the credit limit rule is set to block, not warn), or a foreign-currency rate that is not in the exchange-rate table for the posting date. All four are deterministic and all four need a human, not a retry.

Incoming Payment: where the matching step is the work

The Incoming Payment screen is the densest step in O2C and the one most likely to look small to someone who has not run an AR team. The shape of the work is: a wire arrives for a customer, the customer has multiple open invoices, the wire amount does not cleanly match any single one, and the AR clerk decides which invoices to fully apply, which to short-pay, which to leave on account, and whether to charge a write-off difference.

Service Layer and DI API both accept an Incoming Payment with pre-resolved allocations. Neither does the matching itself. The shape that ships is to read the bank file (BAI2, MT940, camt.054, or a CSV from the customer's online banking export), score each open invoice for that customer against the wire amount and any reference field, propose a most-likely allocation set, and drive the Incoming Payment screen to apply that proposal. The AR clerk reviews the proposed split before clicking Add.

The structured matching pass takes a few hundred milliseconds. The screen drive takes about 45 seconds for a wire against two open invoices. The clerk review is the slow part, and it should be: AR is an audit-sensitive function and the human approval is what keeps the controls clean.

SAP Business One O2C automation: questions teams ask before they pilot