Order extraction into the ERP, 3-way match for delivery notes and invoices, sales agents that read Business Partner history — always with idempotent writes, validation against the catalogue and full respect for B1 User Authorizations.
SAP Business One holds the inventory, the catalogue, the price lists and the accounting. An AI that writes without understanding the Business Partner, Item and marketing document model breaks the close, inflates stock or duplicates an order on a timeout. Anything that happens in B1 ends up on the balance sheet — and that is audited by the tax authority, not by a dashboard.
We work by the rule of reading a lot and writing little — and only when the operation has been validated against the catalogue, the active price lists and the User Authorizations of the user triggering it. Every write carries an idempotency key, a dry-run mode for review before commit, and an auditable log. The test company exists for a reason: that is where we validate the flow before touching production.
PDF, email or Excel from the customer — the agent extracts lines, cross-checks them against Items and the Business Partner’s active price list, and creates the Sales Order in B1 via Service Layer. Anything that doesn’t match lands in a queue for review; the agent doesn’t make codes up.
Reads the purchase order, the goods receipt and the supplier invoice, reconciles them at the line and quantity level, and flags deviations. Only what matches automatically is proposed for posting — the rest goes to the reviewer with the reason.
Reads order history, applied price lists, payment terms and customer rotation directly from B1 and prepares a draft quote with real product, price and lead time. The sales rep reviews and signs off — the agent doesn’t set off-policy prices.
Watches Item levels per Warehouse, cross-references historical rotation and supplier lead time, and proposes replenishment — the proposal stays as a draft so the purchasing lead can convert it into a Purchase Order if they agree.
Ask in natural language about sales, margins, rotation or receivables — the agent generates the query, runs it against HANA or MSSQL and returns the answer citing the exact SQL. If it isn’t sure, it says so and doesn’t invent the figure.
Service Layer is the standard path for Sales Orders, Business Partners, Items and most marketing documents. For operations only exposed by DI API (some legacy or partner-customised action) we run DI through a dedicated service, never mixed into the same agent process.
The agent acts as a B1 user you authorize the same way you would a person — no permission bypass, no superuser. If the user can’t create a Credit Memo, neither can the agent. The ERP owner audits that, not us.
Before writing, the connector resolves the CardCode of the Business Partner and the ItemCode against the real catalogue. We don’t auto-create new customers or items by default: anything that doesn’t resolve lands in a supervised queue. We work with messy master data, but we don’t silently fix it.
Every write carries a unique key that we persist either in a document UDF or in an auxiliary table. If the agent retries on a timeout, we check the key before executing and the operation is applied exactly once — no duplicate orders, no double invoices.
We support both engines — semantic reports differ between HANA and MSSQL and we account for that. Any new flow is tested first against a test company that mirrors your real UDFs and authorizations before touching production.
Both. The orchestration layer is the same; what changes is the analytic query dialect and a few Service Layer details. If you’re on HANA we also expose the semantic views; if you’re on MSSQL we work with the equivalent views and stored procedures. We confirm it during initial discovery.
Every write carries a unique idempotency key that we store in a document UDF or an external table. Before creating a Sales Order, the connector checks that key; if it already exists, it returns the original document without writing again. A network timeout does not produce a duplicate order.
Not by default. We read your UDFs if they’re part of the model (for example, an external key or a process flag) and we only write to UDFs you explicitly authorize. Any SDK add-on you already have keeps working — the agent operates above the Service Layer, it doesn’t compete with it.
It lands in a review queue with the reason: unresolved ItemCode, unknown CardCode, price out of range, inconsistent quantity. The owner sees it, decides whether to create the item, assign manually or reject, and the agent learns from the pattern for similar cases. We never write to the ERP with a made-up code.
We design for privacy from the start, human control, traceability, usage limits, permissioning and documentation. For sensitive processes, we help assess risk and applicable obligations under GDPR and the EU AI Act.
Every engagement is led personally by one of the partners. If there's a fit, you get a personal first read of your case within one business day — not a canned demo.
