CERTAINCE Logo

Automate Business Processes: Custom Software, AI Agent or Off-the-Shelf Tool?

AI Automation · 10 min

Illustration: automated business processes. Process flowchart with gears and one golden path

At month-end, every account movement at MAFU-SHERPA is already sitting in Business Central. Someone still opened a spreadsheet and rebuilt, by hand, the booking batch that DATEV accepts. Almost every company knows this moment under a different name: the weekly report, the price list, the transfer into payroll. The numbers are rarely the problem. The problem is the handover between two systems that both work correctly and still do not speak the same language. If you want to automate business processes, the decision starts right here, and the tool comes afterwards.

In the DATEV export at MAFU-SHERPA, four details decide whether the import file is accepted at all. The sign coming out of Business Central has to be translated correctly into a debit or credit indicator. Amounts need the German decimal separator, empty DATEV fields have to be set correctly, and every mandatory column has to arrive in the required order. None of these four rules is a matter of taste, and each one separates an accepted import file from a rejected one. As long as the export was produced by hand, that mapping was re-explained in spreadsheets every closing cycle.

That project left us with a rule we have worked by since: automate the smallest recurring handover whose rules can be written down and whose result can be checked. Both halves belong together, because a rule nobody can write down is also a rule nobody can sign off later.

What we actually built at MAFU-SHERPA

Business Central remains the system of record for the posting data. Next to it runs a lean, custom-built application that reads the filtered export, processes only general ledger accounts with movements and writes posting records with amount, debit or credit indicator, account, contra account, document date and booking text. What comes out is an EXTF CSV file with metadata, the complete column structure and Windows-compatible line endings. Users upload the export by drag and drop, and a person reviews the transformed data in a preview before the import runs. The DATEV export became a repeatable step instead of a spreadsheet task rebuilt from scratch every time.

An AI agent could have taken this step over as well, and we deliberately decided against one. That is our judgment rather than a finding from the project: where a mapping is fixed and every line follows the same four rules, an agent is the more expensive option and the harder one to verify. An agent that decides differently than it did on the previous run makes an accounting handover unpredictable. We use agents where the rule cannot be written down in advance, and that was not the situation here.

Four ways to automate a workflow

This decision comes up again in every project, and it comes down to four shapes. The grouping says nothing about how big the solution is, because a small automation can still involve custom code and a small interface of its own, as the DATEV export shows. What separates the four shapes is the responsibility the solution takes on.

  • Use an off-the-shelf tool better. Configuration, clear fields and discipline in the existing system are often enough, and no new software joins the stack.
  • Small automation. A fixed workflow with fixed rules, such as a form, an approval, a status change or a recurring handover between two systems.
  • AI agent. Fits where something has to be read and compared and the right answer only shows up case by case, with permissions, logs, tests and human review.
  • Custom software. Fits where your own rules and exceptions, different responsibilities, connections to existing programs or external users come together.

For the DATEV export, the right shape was the small automation, even though it took custom code and an interface of its own. The standard system delivered the data but not the format DATEV requires. Going the other way, a large application would have been too much, so the solution stayed deliberately lean and can be extended if cost centers or BU keys are needed later. The shape follows the responsibility of the workflow, not the effort it happens to create.

A common shape of small automation is a low-code app. At MAFU-SHERPA, stocktaking in a spreadsheet became increasingly error-prone as the number of items grew, especially on the shop floor. The company was not yet ready for a full ERP system, so a barcode app on Microsoft Power Apps took over: it reads items at the storage location, assigns stock to projects and writes changes back to the existing spreadsheets. The solution stayed deliberately small and followed the next necessary step.

With any platform, the important habit is to name its documented boundaries before the start and record them as exit criteria. In Power Apps, a nondelegable query is evaluated locally over only the first 500 records, or at most 2,000; with larger data sets this produces incomplete results. Knowing such mechanics up front lets you extend the app deliberately or complement it with a custom application at the right time, instead of discovering the boundary during troubleshooting.

How to tell which shape fits your workflow

You can work through these five questions in your next internal meeting, before you talk to any provider.

  • Can you write down the rule for the normal case in three sentences? If you can, you do not need an AI agent for it.
  • How would you notice that the result is wrong? Without that answer there is nothing to sign off, whichever shape you pick.
  • How often does the exception occur, and who decides it today? Frequent exceptions are the reason small automations fail.
  • Which existing programs have to deliver or receive the data? Every additional connection is a work item of its own.
  • Who in the company answers for the data once the step runs automatically? If that person is not named, the workflow is not ready to be automated.

The answers usually push the decision a long way in one direction on their own. Whether a bought product or your own development wins comes down to the same points, and the comparison of off-the-shelf and custom software puts them side by side.

Where an AI agent belongs

An AI agent rarely solves a whole workflow on its own. It takes on one clearly bounded task, such as reading and comparing data or drafting a reply, while the frame around it stays real work. That frame means reliable data, suitable permissions, logs, defined error paths and a point where a person checks the result. The agent earns its place where the rule cannot be written down in advance, because every case looks different. For the DATEV export that rule could be written down; for the sales research we built for the same company it cannot, because every company website hides its signals somewhere else.

How much such an assistant actually helps depends on the task and on the people doing it. A field study of 5,172 support agents measured 15 % more issues resolved per hour on average. The average hides how far the effect diverged by experience and by task type. The study observed a single setting, so the figure does not transfer to office work in general. For the decision at hand, the finding matters more than the percentage: the task and its users determine the benefit.

The same question in other workflows

  • Quoting and configuration. The CPQ configurator at MAFU-SHERPA produces bills of materials, routings and quotes from structured requirements instead of assembling them in spreadsheets. It was built as a custom extension inside Business Central.
  • Inventory and project status. XPO Inventory brings stock, reservations and project status into one system, with barcode capture and offline queues for work on the warehouse floor. Here a custom application was the right shape.
  • Sales research and qualification. The AI-supported research solution for MAFU-SHERPA scores buying signals on company websites and turns them into prioritized leads with matching conversation angles. Here AI carries the core of the task, because judging a company cannot be expressed as a fixed rule.

Part of the payoff is simply faster workflows. The other part is the work nobody ever started, because it did not fit around the day-to-day: the campaign for a new customer segment, the recurring report, the analysis of your own order data. Using AI in your business takes on exactly those cases, including the places where AI is not worth it yet. The industry view is on the pages for Software for machine builders and Software for exhibition stand construction.

What automating business processes costs

A flat price is not much help here, because the effort does not sit in the amount of code. It sits in how clear the rules are and how clean the data is. Then come the exceptions, the existing programs that have to deliver or receive data, and the question of who in the company answers for the automated step. Maintenance and review come last, and they arrive even when AI makes the building itself much cheaper. How Much Does Custom Software Cost? works through the questions that determine the effort in a specific case.

In our experience the weight usually sits on the first point. For the DATEV export, each of the four rules had to be captured and agreed before the transformation could be built at all. AI makes the first version fast, and the rest of the work is still there. AI Software Development describes what turns that speed into a solution somebody can maintain.

Which business processes are worth automating?

A workflow is worth automating when it recurs often enough that people remember it, and when a person could tell on the same day whether the result is right or wrong. Two exclusions help as well. If the workflow keeps changing, or if nobody in the company answers for the result, automation costs more than doing the work by hand.

When does an AI agent replace a screen or a single step?

An agent normally replaces a step rather than the application around it. That makes sense when the input arrives unstructured and a person would otherwise have to read, search and classify it before deciding. When the input stays structured and the rule stays the same, a fixed automation is cheaper and easier to verify.

Where do automated workflows need permissions, logs, tests and human review?

Wherever a mistake cannot easily be undone. The technical account should only see the data the step really needs, and every change belongs in a log that records when it happened and what triggered it. A test run with real examples has to be allowed to fail without doing damage. Human approval belongs in front of any step that changes payments, delivery commitments or customer data.

You do not need a requirements document for this. Take one handover that costs manual work every month and record its trigger, inputs, exceptions and expected result. Discuss a concrete workflow.

Inquiries