Skip to main content
LR Services Business Central

Practice 03

AI that does actual Business Central work.

Not a strategy engagement. Two halves of one job. Implementation, which is deciding where AI actually helps, getting the data underneath it into shape, and putting the result inside the Business Central workflows people already use. And the tooling itself: assistants over live BC data, document intake, chat and voice front ends, agents, retrieval and anomaly surfacing.

Discuss an AI pilot See what we do
  • 6 tools, one team that builds both layers
  • Runs on your BC permissions
  • Measured on hours saved
An AI assistant answering a question against Business Central data A Business Central record panel on the left feeds an assistant panel on the right, which returns an answer with the source records it cited. A supplier invoice flows in from below and is drafted into a document record. BC TABLES INVOICE DRAFT ยท AWAITING APPROVAL Answers cite the records they used

Our position

The value is in the boring work

The AI projects that fail in ERP are the ones that start with the technology and go looking for a use. The ones that work start from a specific task that takes a specific person a specific number of hours a week, and end with that number lower.

We also treat this as ERP work rather than as an experiment parked next to the ERP. Anything we build runs against your Business Central permissions, so a user cannot ask an assistant for figures their own login would not show them. Every action an agent takes lands in BC as a normal, auditable record with a traceable origin. Where the model is uncertain, it drafts and a person approves rather than posting quietly and hoping.

AI implementation

Getting it into a business that is already running

Implementation is most of the work and almost none of the conversation. Something that answers well in a demo still has to sit inside a live Business Central, on real permissions, in front of people who already have a day job. This is the sequence we run, and stopping partway through it is a legitimate outcome that we price for.

  1. Assessment

    We walk the actual work and sort it into three piles. Tasks where AI takes hours out. Tasks where a report, a page change or a small AL extension takes more hours out for less money. And tasks that should not be automated at all. The second and third piles are usually larger than people expect, and we say so before anyone has spent anything.

  2. Data readiness

    AI over an ERP is only as good as the data model underneath it. If item categories are inconsistent, dimensions are half populated, or the same customer exists three times, you get confident answers that are wrong, which is worse than no answer. We check the master data, the dimension setup and the document links first, and fix what has to be fixed.

  3. Pilot

    One workflow, fixed scope, running against a copy of real data, with the current hours counted before we start. Small enough that the answer arrives in weeks and cheap enough that stopping is reasonable. A pilot that fails early is a good outcome compared with finding out in year two.

  4. Into the workflow, not beside it

    Production means it lives inside Business Central. The output is a normal BC document on the normal approval route, under the same permission sets, visible to the same people in the same place they already look. If it needs its own screen, its own login and its own thing to remember to check, we have usually designed it wrong.

  5. Adoption

    The technology is rarely what kills these projects. People revert to the old method the first time the new one is slower on a bad day, and nobody mentions it. We train against real cases rather than a sandbox, leave the manual route open at the start, and watch which one people actually use in week six.

  6. Measurement

    Hours before and hours after, error rate, and how often a person had to step in. Measured on the same basis as the benchmark so the comparison means something. If the numbers do not move, we report that plainly and we stop rather than widening the scope and hoping.

Where AI is the wrong tool

We talk people out of this work fairly often. If a task is exact and rule bound, such as a tax determination, a posting routine or an allocation with a defined formula, then ordinary code is faster, cheaper and correct every single time. An AL extension is the better answer and we will say so.

If the volume is low, there is no business case. Somebody doing a task twice a week is not a problem worth a project. If the process is undocumented and comes out differently depending on who runs it, the process is the problem, and putting AI on top of it mainly makes the inconsistency harder to see. And if the output has to be exactly right every time with no human check, that is automation, not AI, and it should be built as automation.

The honest test is whether somebody in the room can describe what a good result looks like. If nobody can, the project is not ready yet, whatever the technology.

AI tools

The tooling layer, and what each piece is for

These are the components we build with. Most engagements use one or two of them rather than all six, so what follows is what each one is genuinely good at, and where it stops being the right answer.

Assistants and copilots over BC data

Plain-language questions answered against live BC data. Which customers are over their credit limit and shipping this week. Why this item's margin dropped last month. What changed on this purchase order and who changed it. It reads through the same permission set as the person asking, and it cites the records it used, so the answer can be checked rather than trusted.

Good for the questions people ask constantly and answer slowly, usually by exporting to Excel. Not a substitute for a reconciled statutory report, and we do not present it as one.

Permission-scoped Cited answers

Document intake, OCR and extraction

Supplier invoices, packing slips, order confirmations and remittance advices read on arrival, matched against the purchase order or receipt, and turned into a drafted BC document with the lines populated. Clean matches flow through. Anything ambiguous goes to a person with the original document on screen next to the draft.

Good wherever high volumes of paperwork arrive in a format nobody controls. This is usually the fastest payback of the six and the easiest one to measure.

Fastest payback Human approves exceptions

Chat and voice front ends

The routine lookups and transactions that do not justify opening the client, handled in Teams, in a browser or on a phone call. Check stock in another location. Raise a requisition. Answer an order status or an invoice query while the customer is still on the line. Submit a timesheet or a job entry from the floor.

Voice earns its place where hands are busy or the person asking is outside your business. Good for cutting casual logins and interruptions. Poor for anything that needs a screen full of context in front of you.

Teams, mobile or voice Fewer casual logins

Agentic workflow automation

Chaining steps rather than answering one question. Multi-step processes that currently need a person to shepherd them: chasing unconfirmed purchase orders, matching remittances to open invoices and flagging short payments, watching open documents for the exceptions that become a month end problem. The agent runs the sequence and escalates the judgment calls.

Good where the sequence is stable and the exceptions are rare and recognisable. A process that branches unpredictably at every step is a process problem first.

Every step logged Escalates judgment calls

Retrieval over internal documentation

Your process notes, work instructions, policies, supplier terms and the institutional knowledge sitting in old email and SharePoint, made answerable in plain language. Every answer links back to the document it came from, so the reader can open the original instead of trusting a summary.

Good for onboarding, for support desks, and for the question only one person in the building can currently answer. It works on what you have written down, so it is also an honest audit of what you have not.

Links to the source Onboarding and support

Reporting and anomaly surfacing

Rather than somebody reading a report looking for what is wrong, the system watches and raises it. A margin that moved. A supplier price that drifted across three orders. A posting pattern that does not match the last six months. A cost that landed in a dimension it has never used before.

Good as an early warning in the week before month end, when there is still time to correct something. It points at where to look. The decision stays with your controller.

Early warning Points, does not decide

How we build it

The AI layer and the ERP layer, built by the same team

Several of our team members are full stack developers. That is what makes this practical rather than theoretical: front end, back end, database and deployment on one side, and Business Central, AL and the posting model on the other, inside one team that talks to itself.

Most AI work around an ERP fails at the seam. An AI vendor builds something capable that needs data out of Business Central. A BC partner builds an integration to feed it. The two of them meet in a specification that neither of them owns. Then the extraction misses a line, or a permission is wrong, or an update wave changes a page, and both sides can point at the other, and both of them are partly right.

We do not have that seam. The people writing the retrieval, the extraction and the interface sit with the people writing the AL extension and the API pages, so deciding where a piece of logic belongs is an internal design conversation rather than a change request between two companies. In practice that means scoping is faster, the estimate is one number, and there is one party accountable when something is wrong at half past four on a Friday.

It also means we are free to recommend against AI. If the right answer is an AL extension with no model in it anywhere, we can build that instead, and no commercial interest of ours is arguing with the recommendation.

Front end
Web application, Teams surface or voice front end, built by the same people who build our customer and supplier portals.
Service layer
Model orchestration, retrieval, document extraction, the tool definitions an agent is allowed to call, plus queues, retries and logging.
Integration
API pages, authentication and the BC web services layer, written to the same standard as our AppSource work rather than as a one-off script.
Business Central
AL extensions, tables, permission sets and the posting behaviour that everything above has to respect. This is the part outside specialists usually get wrong.
Run and support
Environments, release process, update wave testing, and named people who answer when it breaks.

Data and governance

Where your data goes, and what we will not claim

Access follows the user's own BC permissions, never a shared service account with broad rights. Anything that posts to the ledger is drafted for human approval unless you explicitly decide otherwise for a low-risk document type. Every AI-originated record is identifiable as such and traceable back to its source document or prompt.

On data handling we would rather give you the truth than a badge. LR Services is a consultancy rather than a hosting provider, and we are not going to put a compliance logo on a web page for a standard we have not been audited against. What we will do, in writing and before anything is connected, is set out which components touch your data, whether any of it leaves your Microsoft tenant, what is retained and for how long, and what the alternatives are if that answer does not suit you.

Where the requirement is that nothing leaves the tenant, say so at the start. It genuinely constrains the design, and it is far cheaper to know on day one than after a pilot has been built. Whatever we see on your engagement is used to do your work and is not reused to build something for another client.

See the Business Central practice

  • User permissions, not a service account. An assistant cannot return figures the person asking could not open themselves.
  • Drafts by default on anything that posts. A person approves before the ledger moves, unless you decide otherwise for a low-risk document type.
  • Every AI-originated record is marked and traceable back to the source document or prompt that produced it.
  • Data location and retention settled first. We are direct about where data goes and what is kept before anything is connected, because that answer usually decides the architecture.
  • Your data is not our material. What we see doing your work stays for doing your work. It is not reused to build something for another client.
  • Practice, not credentials. We describe how we work and we will answer any question about it. We do not claim certifications or standards we have not been audited against.

Next step

Name the task that eats the most time

Tell us the single most repetitive job in your finance, purchasing or warehouse team. We will tell you whether it is a good candidate, what a pilot would look like, and what it would take to prove it out. If it is a bad candidate, that is a useful answer too.

Discuss an AI pilot sales@lrservices-us.com