Order management software: orders arrive five ways and someone retypes them by hand

The head of the order office at a distributor of spare parts and components for plumbing and heating systems near Brescia, thirty employees and nine million euros in revenue, has a ritual everyone knows: at ten past eight on Monday he opens the orders inbox and reads the number in bold next to "Inbox". Sixty-three messages. Among them there are real orders, but also confirmations of orders already given by phone, a photo of a delivery note written by hand by an installer, an Excel file with a column of codes nobody recognises and a message from the agent for the Verona area that says only "as agreed, same stuff as last month".

Here you will find what "order management software" really means and what it is not, the two numbers that tell you whether you need it or whether a better kept accounting system is enough, the calculation of what the order retyped by hand costs you every year, three calculations written in code that you can redo with your own data, and the threshold above which a custom piece pays for itself. The case that follows is a typical case, rebuilt from situations I have seen in companies that sell to other companies, with rounded numbers.

What order management software is, and what it is not

The search "order management software" gathers very different tools, and whoever chooses the wrong one finds out when the office keeps retyping the same codes. It is worth separating them straight away, because each one solves one piece and leaves others uncovered.

The first is the ERP or accounting system, the program that holds records, stock, bookkeeping and invoices. It almost always has an orders module, and the module is made well for one precise thing: recording an order that someone has already decided to enter. It does not go and fetch the order where it is born. It starts when a person opens the screen and begins to type lines.

The second is the e-commerce shop, the online store. It is excellent when the customer chooses alone from a catalogue, with prices that are the same for everyone or nearly so. But a company that sells to installers, resellers and businesses has price lists per customer, tiered discounts, different payment terms and customers who do not want to stop emailing their usual contact. The shop intercepts a part of the orders and leaves out the rest. I wrote about how the two systems talk to each other in the article on integration between accounting system and e-commerce.

The third is the B2B portal, the reserved area where the customer logs in, sees their own price list and reorders in a few clicks. It is the right road for customers who reorder the same things every month, and I covered it in the article on the B2B portal. Its limit is that it works with those who use it. If your best customer is sixty and has been ordering by phone since 1998, the portal remains a nice program he will never open.

The fourth is EDI, the exchange of order documents between computers in a standard format. Large retail chains and some large industrial customers ask for it. It is rigorous and expensive to start, and it almost always concerns a few very large customers, not the fourteen hundred small ones who make most of the lines.

The fifth, and the one that matters to whoever is reading, is the set of rules and memory between the moment the order arrives, in whatever form, and the moment the goods leave: where it comes from, who takes it on, whether it is the same as one already received, whether the codes are right, whether the goods are really there, when they can leave, what is promised to the customer and who answers them. This is not a module. It is a process, and it has a time, a cost and an error rate that can be measured.

Order request, order, confirmation: three moments with different rules

In everyday speech "order" is everything that comes from the customer. In the system it is worth distinguishing. The order request is what the customer sends, in whatever form, clean or messy. The order is the request after someone, or something, has checked customer, codes, prices and quantities. The confirmation is the reply that tells the customer what they will receive, how much they will pay and when. Between the first and the second there is the cleaning of the data, between the second and the third the check of the goods. Almost all the trouble comes when the three moments merge into one, done by a person in a hurry.

If a quote comes before the order, the discussion changes, and I wrote about it in the article on quotation management software. Here we are talking about the order that arrives from customers who already know your prices: spare parts, supplies, consumables, everything sold from a catalogue and an agreed price list.

What it must be able to do, one line per function

A useful system holds six things together: the single entry point for all channels, the reading of lines with the check of codes and of the customer's prices, the search for duplicates, the check of real availability, the confirmation with a date that can be kept and the follow-up up to shipping. Every product on the market does one or two of these well. Almost none holds all six in the same place, and that is where the Monday morning inbox is born.

Why the order gets dirty along the way, without anyone really making a mistake

At the Brescia company nobody worked badly. The four people in the order office knew the customers by name, knew the best-selling codes by heart and answered the phone on the second ring. Every single gesture was correct. What did not work was the number of times the same order was read, interpreted and rewritten by someone.

We followed it over a year of data. Out of twelve thousand orders, 5,520 had arrived by email, 2,880 by phone, 2,160 through the nine agents and 1,440 from the portal and the website form. Only the last group, 12 per cent, entered the accounting system without anyone retyping it. The remaining 88 per cent, that is 10,560 orders, went through the hands of a person who read a message, a note or a voice on the phone and rewrote lines, quantities and references into a screen.

Every rewrite is a small bet. A code with two digits swapped, a quantity read from the wrong line, a pack of ten mistaken for a pack of a hundred, the customer who orders "the usual fitting" and the clerk who remembers the one of another customer. None of these errors is a serious lapse. They are errors of repetition, and repeated twelve thousand times a year they make a number you can see.

The three points where the order gets dirty

The first is entry through several channels without a single list. Orders arrive from five places: the shared inbox, the agents' personal inboxes, the office phone, the phones of those at the counter, the website form. Nobody knows how many orders are waiting, and when an agent is on holiday the messages customers write to him stay where they are. The customer, who wrote to "an address of the company", considers the order placed.

The second is availability promised without really looking at the warehouse. The accounting system says there are 140 pieces of a fitting in stock. What it does not say, or says on a separate screen that nobody opens, is that 118 are already committed to other confirmed orders and that the incoming goods are still on the truck. The clerk promises delivery for tomorrow because the big number is 140. The next day the warehouse ships 22 pieces out of 30, and the customer ends up with half a delivery and an order still to close.

The third is the confirmation that goes out late or does not go out. If the confirmation depends on a person who first rewrites, then checks, then replies, the time between the order and the reply is that of the office's work queue, not the one the customer expects. At Brescia the confirmation arrived on average after 1.9 working days, and for 28 per cent of orders, that is 3,360, after more than two days. An installer whose site is at a standstill waits for your reply to decide whether to order elsewhere.

All three points show up in a day, if the data is in one place, and show up in a year if it sits in the heads of four people. And this is the difference that order management software must produce: not making people work faster, but making sure the order is written once.

Small customers, resellers and large customers: where the problem changes

With small customers, installers and maintenance firms, the problem is form. They order in a hurry, with one-line messages, sometimes with a photo of the broken part. The value lies in interpreting well and answering early: these are customers with no time to wait, and a supplier who answers in an hour is worth more than one who costs two per cent less.

With resellers the problem is volume and repetition. They send long orders, with thirty or forty lines, almost always similar to those of the month before. An error on one line is easy to make and hard to find. Here the portal and order templates pay off a lot, because the customer chooses from a list they know.

With large customers the problem is the rule: delivery times, packaging, documents, sometimes an EDI layout. Here the error is not a nuisance, it is a penalty written into the contract, and the rules must be kept in the system and not in the memory of whoever understood them once.

The real cost: what the order retyped by hand costs every year

Before talking about software it is worth doing the sum of today's situation. In the Brescia case there were five items. I give them with the method, so that you can redo it with your own numbers. I have left out the cost of the warehouse and of logistics itself: it is real work, and no order program does it in your place.

The premises are few. The company handled 12,000 orders a year, about fifty every working day, with seven lines on average and an average value of 750 euros, that is nine million euros in revenue. The gross margin was 24 per cent, so about 180 euros on an average order. Active customers were 1,400. An hour of office time cost 34 euros, everything included.

Avoidable retyping hours. Rereading an order, finding the customer, looking for the codes, checking the price they are entitled to and writing the lines took 12 minutes on average. With a system that reads the order and proposes the lines, four minutes of checking are left to the person. That is eight minutes saved on 10,560 retyped orders, that is 84,480 minutes, 1,408 hours, which at 34 euros make about 48,000 euros a year.

Wrong lines and returns. 9 per cent of orders, 1,080 a year, had at least one wrong line: a code, a quantity, a pack. About a third of these, 380, reached the customer, who sent them back: round-trip transport, putting back on the shelf, credit note and new invoice cost on average 95 euros, 36,100 in all. The other 700 were stopped in the warehouse with a phone call and about half an hour of work between two people, 17 euros each, that is 11,900. That is about 48,000 euros a year.

Orders shipped late or in part. 14 per cent of orders, 1,680, left late against the promised date or with missing lines, because availability had been promised by looking at stock and not at what was already committed. Each case meant a second shipment, 22 euros of transport, and about 14 minutes of chasing, phone calls and rescheduling, 8 euros. Thirty euros for 1,680 orders make about 50,000 euros a year.

Customers lost to delays. Every year some forty customers sharply reduced their purchases or stopped ordering. Asking those who answered for the reason, for half of them, about twenty, half deliveries, missed dates or repeated errors came up. An average customer is worth 6,400 euros of revenue and about 1,540 of margin a year. Twenty customers times 1,540 make about 31,000 euros a year, and the number is prudent, because I counted one year of lost purchases only.

Time lost chasing orders. Six people, four from the office and two from the counter, lost on average two hours a week answering the question "where is my order", looking for an email, checking with the warehouse what had left. Two hours for forty-six weeks for six people make 552 hours, which at 34 euros are about 19,000 euros.

The total is about 196,000 euros a year, 2.2 per cent of revenue, in a company with an operating margin of 5 per cent, that is 450,000 euros of profit. Put another way: more than 40 per cent of the profit went away in the way orders came in and were confirmed, not in the prices, not in the products and not in the warehouse.

Two honest caveats. The first: the items on delays and lost customers are in part missed earnings, not accounting losses, and they overlap, because an order with a wrong line is often also an order shipped late. The second: the hours item is the most solid, because it is measured with a stopwatch, and that is why I treat it differently when I calculate the threshold further on.

Your sum will be different, but the items are almost always these five. If the total, redone with your numbers, is below 0.8 per cent of revenue, order management software is not your priority. If it is above 1.5, it almost certainly is, even if nobody in the company calls it that.

How to redo the sum in an afternoon

You need five data points, and almost all of them are in the accounting system and the mail. The first is the number of orders in the last year and their average value. The second is the share that arrives from channels that force someone to rewrite: email, phone, agents, everything except a portal or a file read by the program. The third is the entry time: have three people time ten real orders, without saying it is a test. The fourth is how many orders had a correction after confirmation, a return or a credit note. The fifth is the average gross margin, which your accountant knows.

With these five data points the items calculate themselves. No analysis is needed, only honesty about the fact that the real time is almost always double what you think, and that the errors remembered are fewer than the real ones, because only those that reached the customer are remembered.

The number that decides: how many orders are retyped by hand, and how many come out right the first time

The sum of the five items tells you how much you lose. It does not tell you whether software will make you recover that money, because a part depends on commercial decisions that no program makes. The number that tells you is another one, and I call it the share of orders retyped by hand: the percentage of orders that a person has to rewrite into the accounting system because they are not born in a form the program can use.

The thresholds I use are four. Below 25 per cent the situation is under control: the accounting system you have is enough, kept with care, and perhaps a portal for customers who always reorder the same things. Between 25 and 50 the problem is one of method: work arrives in scattered order, and before writing code you need to decide which channels to keep and who covers them. Between 50 and 75 a system that reads and proposes the lines pays for itself, because the delay is structural and no discipline removes it. Above 75 the order office is mostly acting as a copyist: the most expensive work in the company, that of people who know the customers, is copying from one place to another.

At the Brescia company the share was 88 per cent, in the highest band. And the distribution said more than the average: resellers with thirty-line orders were the most exposed, because every extra line is one more chance to get it wrong, and their share of lines correct the first time was the lowest.

The second number: how many orders come out right the first time

Next to the share I measure a second one: the percentage of orders right the first time, meaning with no correction after confirmation, no return and no credit note for an order error. Above 98 per cent you are working well. Between 95 and 98 there is a problem of method. Between 90 and 95 an automatic check of codes and quantities pays for itself. Below 90 one order in ten comes back, and customers' trust wears out faster than the accounting figure would suggest. At Brescia it was 91.

The two numbers tell about two different points of the same flow. The first says how much copying work you are paying for, the second what that work costs when it is done badly. You can have one good and the other bad, and the remedies are different: in the first case you work on the entry, in the second on the checks.

A third number, which the customer sees before the others: confirmation time

The customer does not see your screens. They see only how long passes between the moment they send the order and the moment they receive a confirmation with a date. I measure it in working days, and it is the first thing that changes when the system works: from the almost two days of Brescia you can drop to a few hours for the great majority of orders, because the confirmation no longer waits for someone to retype.

How to calculate them, with the data you have

You do not need a new system for the first measurement. You need the date and channel of arrival of each order, the date of confirmation, and a list of later corrections. If the channel is not written anywhere, it is rebuilt from the mail and the switchboard logs. For working days you need a calendar with holidays set to zero. With this data the measurement is a query.

-- Orders retyped by hand, orders right the first time and confirmation time, last twelve months.
-- Calendario(Giorno date, Lavorativo bit): one row per day, holidays and bridge days set to zero.
-- Correzioni(IdOrdine, DataCorrezione): lines changed after confirmation, returns, credit notes for order errors.
WITH Base AS (
    SELECT o.IdOrdine,
           CASE WHEN o.Canale = 'Portale' THEN 0 ELSE 1 END AS Ribattuto,
           CASE WHEN EXISTS (SELECT 1
                             FROM Correzioni AS c
                             WHERE c.IdOrdine = o.IdOrdine)
                THEN 0 ELSE 1 END AS GiustoAlPrimoColpo,
           conf.GiorniLavorativi
    FROM Ordini AS o
    CROSS APPLY (SELECT COUNT(*) AS GiorniLavorativi
                 FROM Calendario AS g
                 WHERE g.Lavorativo = 1
                   AND g.Giorno >  CAST(o.DataRicezione AS date)
                   AND g.Giorno <= CAST(o.DataConferma AS date)) AS conf
    WHERE o.DataRicezione >= DATEADD(month, -12, CAST(GETDATE() AS date))
      AND o.DataRicezione <  DATEADD(day, -30, CAST(GETDATE() AS date))  -- only orders with at least thirty days of history
      AND o.DataConferma IS NOT NULL
)
SELECT COUNT(*) AS Ordini,
       CAST(100.0 * SUM(Ribattuto) / COUNT(*) AS decimal(5, 1)) AS PercentualeRibattuti,
       CAST(100.0 * SUM(GiustoAlPrimoColpo) / COUNT(*) AS decimal(5, 1)) AS PercentualeGiustiAlPrimoColpo,
       CAST(AVG(1.0 * GiorniLavorativi) AS decimal(5, 1)) AS ConfermaMediaGiorniLavorativi,
       CAST(100.0 * SUM(CASE WHEN GiorniLavorativi > 2 THEN 1 ELSE 0 END) / COUNT(*) AS decimal(5, 1)) AS PercentualeConfermatiOltreDueGiorni
FROM Base;

The query returns five values: how many orders, the share retyped, the share right the first time, the average confirmation in working days and the percentage of orders confirmed after more than two days. Two caveats. The first: if the arrival channel has never been written down, the missing data is already a result, and an ugly one, because it means nobody knows where orders come from. The second: the date that counts is the one on which the order arrived, not the one on which someone opened it. They are different days, and the first is the one the customer sees.

Real availability: the price and the date you can promise

Almost all the value of order management software, after the single entry point, lies in one function: telling the customer only what can be kept. Three numbers that today sit in three places must be put side by side, for each line: the physical stock, the quantity already committed to other confirmed orders and the goods incoming with their date. The difference between stock and committed is the free quantity, and only that can be promised right away.

The part that seems trivial, and is not, is the calendar. A delivery promised for Saturday in a company that does not ship on Saturday is a wrong promise, as is goods arriving on Friday afternoon declared shippable the same day. The system must count working days, and must know at what time the company closes shipments.

A calculation you write in an hour

Here is the core in C#, with the minimum types. For each line it says how many pieces can be shipped right away, how many later and with which date, or that the line cannot be promised. It does not decide in place of the person: it writes into the confirmation what is true and flags what is missing.

// Delivery promise for an order line: free stock, incoming goods, shipping cut-off time.
public sealed record Disponibilita(string Codice, int Giacenza, int Impegnato, int InArrivo, DateOnly? DataArrivo);

public enum EsitoPromessa { Pronto, Parziale, Differito, NonPromettibile }

public sealed record Promessa(
    string Codice, int Richiesta, int Subito, EsitoPromessa Esito, DateOnly? ConsegnaCompleta, string Nota);

public static class PromessaDiConsegna
{
    private static readonly TimeOnly ChiusuraSpedizioni = new TimeOnly(15, 0);

    private static bool Lavorativo(DateOnly giorno) =>
        giorno.DayOfWeek != DayOfWeek.Saturday && giorno.DayOfWeek != DayOfWeek.Sunday; // holidays come from the company calendar

    private static DateOnly ProssimoLavorativo(DateOnly giorno)
    {
        do { giorno = giorno.AddDays(1); } while (!Lavorativo(giorno));
        return giorno;
    }

    public static Promessa Calcola(string codice, int richiesta, Disponibilita? d, DateTime adesso)
    {
        if (d is null)
        {
            return new Promessa(codice, richiesta, 0, EsitoPromessa.NonPromettibile, null,
                "Item not in the records: check by hand.");
        }

        var oggi = DateOnly.FromDateTime(adesso);
        var spedizione = Lavorativo(oggi) && TimeOnly.FromDateTime(adesso) < ChiusuraSpedizioni
            ? oggi
            : ProssimoLavorativo(oggi);

        var libero = Math.Max(0, d.Giacenza - d.Impegnato);
        if (libero >= richiesta)
        {
            return new Promessa(codice, richiesta, richiesta, EsitoPromessa.Pronto,
                ProssimoLavorativo(spedizione), "Available: complete shipment.");
        }

        var mancano = richiesta - libero;
        DateOnly? completa = null;
        if (d.DataArrivo is DateOnly arrivo && d.InArrivo >= mancano)
        {
            var spedibile = ProssimoLavorativo(arrivo) > spedizione ? ProssimoLavorativo(arrivo) : spedizione;
            completa = ProssimoLavorativo(spedibile);
        }

        if (libero == 0)
        {
            return completa is null
                ? new Promessa(codice, richiesta, 0, EsitoPromessa.NonPromettibile, null,
                    "Nothing free and no incoming goods that cover the request: a decision is needed.")
                : new Promessa(codice, richiesta, 0, EsitoPromessa.Differito, completa,
                    $"Nothing right away: everything from {completa:dd/MM/yyyy}.");
        }

        var nota = completa is null
            ? $"{libero} right away, no date for the remaining {mancano}: ask the customer."
            : $"{libero} right away on {ProssimoLavorativo(spedizione):dd/MM/yyyy}, the remaining {mancano} on {completa:dd/MM/yyyy}.";
        return new Promessa(codice, richiesta, libero, EsitoPromessa.Parziale, completa, nota);
    }
}

Take the fitting I mentioned before: 140 pieces in stock, 118 already committed, 200 incoming on Friday 9 October 2026. The customer asks for 30 on Monday 5 October at twenty past ten. The free quantity is 22, 8 are missing. The system promises 22 pieces with delivery on Tuesday 6 and the rest, from the incoming goods, shippable on Monday 12 and delivered on Tuesday 13. The old way would have looked at 140 and promised thirty pieces for tomorrow. The customer would have learned the truth two days later, with the site already open.

There is nothing sophisticated, and that is exactly the point. The value is not in the formula: it lies in the three numbers being in the same place, the dates being working dates and the promise being written by a machine every time, not by the memory of someone tired on a Friday afternoon. The other half of the work, keeping stock and incoming goods true, is the one I covered in the article on warehouse management software: if the warehouse lies, the promise lies with it.

What to do when the goods are not enough

The function does not decide what to do with a partial delivery: a rule of the customer does. For some it is better to receive the available pieces right away, for others it is better to wait for everything and have a single delivery, because the transport of two trips costs more than the goods. This preference is written once in the customer record and applied every time. So the confirmation surprises nobody, and the clerk does not have to remember who the customer "who wants everything together" is.

Duplicate orders, wrong lines: the checks that cost nothing

A forgotten item in the sum is the duplicate: the same order entering twice. It happens more often than you would think, and for innocent reasons. The customer sends the email, then calls to be sure, and the clerk who answers retypes it. The agent enters the order the customer had already copied to the office. An order with a defect is sent again "corrected" without saying it replaces the previous one. At the Brescia company duplicates were about 1.5 per cent of orders, 180 a year: most intercepted in time, some not, and those not intercepted became a double delivery and a return.

The check is simple and is written in half an hour. Two orders from the same customer, arriving a few hours apart, are suspect in two cases: they have the same customer order reference, perhaps written differently, or they have the same lines with the same quantities. In neither case does the system discard the order. It flags it to whoever is entering it, with the reason, and the person decides.

// Duplicate flagging: same customer reference, or same lines and quantities, within 72 hours.
public sealed record RigaOrdine(string Codice, int Quantita);

public sealed record OrdineRicevuto(
    string Id, string IdCliente, string? RiferimentoCliente, DateTime Ricevuto, IReadOnlyList<RigaOrdine> Righe);

public sealed record SospettoDoppione(string IdEsistente, string Motivo);

public static class ControlloDoppioni
{
    private static string Normalizza(string? testo) =>
        new string((testo ?? "").Where(char.IsLetterOrDigit).ToArray()).ToUpperInvariant();

    private static string Firma(OrdineRicevuto o) =>
        string.Join("|", o.Righe.OrderBy(r => r.Codice).Select(r => $"{r.Codice}x{r.Quantita}"));

    public static IReadOnlyList<SospettoDoppione> Cerca(
        OrdineRicevuto nuovo, IEnumerable<OrdineRicevuto> esistenti, int finestraOre = 72)
    {
        var riferimentoNuovo = Normalizza(nuovo.RiferimentoCliente);
        var firmaNuovo = Firma(nuovo);
        var sospetti = new List<SospettoDoppione>();

        foreach (var e in esistenti)
        {
            if (e.Id == nuovo.Id || e.IdCliente != nuovo.IdCliente) continue;
            if (Math.Abs((e.Ricevuto - nuovo.Ricevuto).TotalHours) > finestraOre) continue;

            if (riferimentoNuovo.Length > 0 && riferimentoNuovo == Normalizza(e.RiferimentoCliente))
            {
                sospetti.Add(new SospettoDoppione(e.Id, "Same customer order reference."));
            }
            else if (firmaNuovo == Firma(e))
            {
                sospetti.Add(new SospettoDoppione(e.Id, $"Same lines and quantities, received {e.Ricevuto:dd/MM HH:mm}."));
            }
        }

        return sospetti;
    }
}

A case. An installer sends at five past eight in the morning the order with reference "PO 2291/B". At half past four in the afternoon the agent for his area enters the same order with the reference written "po2291b". With spaces, slashes and capitals removed, the two references coincide, and the system warns the clerk before the second order becomes a second delivery. If instead the reference is missing, the other rule applies: the same seven lines with the same quantities, for the same customer, on the same day, is almost certainly the same order.

Checking the codes before they go wrong

The same spirit applies to lines. Even before availability, every line should pass three trivial checks, which nobody does by hand because they are boring: the code exists and is not discontinued, the quantity is a multiple of the pack, the price applied is the one that customer is entitled to on today's date. A line that fails them is not discarded: it is highlighted, and the clerk looks at it first. It is the difference between an office that rereads everything, and for that reason rereads nothing with attention, and an office that looks only at what the system cannot verify.

How order management software must run: from order to shipment

The question I am asked most often is whether it should be a product or a new system. First it is worth understanding what must happen, because the flow is the same whichever road you choose.

Every order enters a single list. Email, phone, agents, portal, photo of a delivery note: whatever the channel, the order ends up in one place with an arrival date, a channel and an owner. You do not need to eliminate channels, you need everyone to write into the same list. At the Brescia company a shared inbox with rules, a three-field form for phones and an address to give the agents were enough.

Lines are read and checked. From the email or the file a draft of lines is derived, and every line goes through the checks: existing code, pack, customer's price. What does not add up is flagged. What is left to the person is the check of what is doubtful, not the copying of what is clear.

Duplicates are flagged. Before accepting the order the system checks whether an identical one exists, and if so says so.

Real availability decides the date. For each line the free quantity, incoming goods and working shipping day are calculated. The confirmation contains only promises that can be kept.

The confirmation goes out with the date. A message to the customer with lines, prices, availability and delivery, in the same channel the order came from. If everything is clear, it goes out by itself after a person's check, within a few hours. If something does not add up, it stays in the queue with the reason written down.

The accounting system receives the clean order. The order enters the accounting system with a single write, with nobody retyping lines, quantities and references. Bookkeeping, invoices and records do not change: this is the piece you keep.

The warehouse prepares the shipment. The warehouse sees an order in which quantities and dates are those promised, and last-minute changes go back to the customer in the same way.

The customer can know where the order is. An address or a page with the status, without phoning. Whoever answers "where is my order" is no longer a clerk looking for an email, it is a screen. A customer who has a visible status stops calling, and that is the 19,000 euro item going down.

None of these steps requires changing bookkeeping or invoicing. At the Brescia company the accounting system stayed the same. What changed was what came before: the inboxes, the scraps of paper and the rereading.

The link with the rest of the company

An order system does not live alone. On the sales side it receives prices and terms from the CRM, and sends back the outcome and the purchase history: the article on CRM software describes the seller's point of view. If for some jobs the order is born from a quote, the data passes from the quotation system without being retyped, and for companies that produce to order the next step is the job, which I covered in the article on job costing software. The boundary between one system and another is always the same: each passes the outcome to the other, neither becomes the other.

What it must not do

A system of this kind must not make the order more rigid than it is. A part of the trade lies in the exception: the long-standing customer who is shipped to before payment, the urgency of an installer with the plant at a standstill, the replacement of a sold-out item with an equivalent agreed by phone. The system must allow all this, asking only that the exception be written down and have a name beside it. A program that prevents making the exception will be bypassed within a week, and the personal inboxes will come back.

How much order management software costs: product, accounting system module or custom

There are three roads, and the prices that follow are those I see in 2026 for Italian companies that sell to other companies, between three and thirty million euros in revenue.

The product. There are ready-made B2B portals and order management programs, with catalogue, price lists per customer, basket and a minimum of file reading. They usually cost between three and twenty thousand euros a year, depending on users, connected customers and functions, with a setup between two and fifteen thousand euros. They do the generic things well: the customer who logs in and reorders. They do less well the particular things of your company: reading the messy email, calculating availability with committed and incoming goods, the checks on duplicates, the link with your accounting system.

The accounting system module. The orders module of the accounting system costs between six and thirty thousand euros in licences and configuration, if you do not already have it. It has the advantage of already knowing records, items and stock. It is designed for orders entered by an operator, and this shows when half the orders arrive by email and phone and the entry screen stays the same.

The custom system. Here too two figures. A custom piece that sits alongside what you have, meaning single entry point, reading of lines with proposal, checks on codes, duplicates and prices, availability check with committed and incoming goods, confirmation with date, order status and link with the accounting system, costs between twenty-eight and sixty thousand euros, plus fifteen or twenty per cent a year for maintenance. A complete system, with allocation rules across several warehouses, EDI exchange with large customers and returns handling, costs between ninety and one hundred and eighty thousand euros and is rarely needed below twenty-five thousand orders a year or if there is a single warehouse.

The threshold, with numbers

The most useful comparison is between staying with retyping by hand and building a custom piece. The cost of the piece is almost fixed, while the cost of the work saved grows with the number of orders.

With the Brescia numbers, the piece cost 38,000 euros, with maintenance of fifteen per cent, that is 5,700 euros a year. Over five years that makes 66,500 euros. Counting retyping time alone, which comes to about seven minutes saved per order once everything is averaged, at 34 euros an hour each order a year of volume is worth about 4 euros a year, almost 20 over five years. The two roads cross at around 3,350 orders a year, about fourteen per working day. Below that threshold, counting time alone, it is better to stay as you are.

// How many orders a year are needed for a custom piece to pay for itself in N years.
public static class Pareggio
{
    public static (int SoloTempo, int ConErroriRecuperati) Ordini(
        decimal costoRealizzazione, decimal manutenzioneAnnuaPercentuale, int anni,
        decimal minutiRisparmiatiPerOrdine, decimal costoOra, decimal erroriRecuperatiPerOrdineAnno)
    {
        var costoTotale = costoRealizzazione * (1 + manutenzioneAnnuaPercentuale * anni);
        var risparmioTempo = minutiRisparmiatiPerOrdine / 60m * costoOra * anni;  // for each order a year
        var risparmioErrori = erroriRecuperatiPerOrdineAnno * anni;               // same, errors and delays avoided

        return (
            (int)Math.Ceiling(costoTotale / risparmioTempo),
            (int)Math.Ceiling(costoTotale / (risparmioTempo + risparmioErrori)));
    }
}

// Pareggio.Ordini(38000m, 0.15m, 5, 7m, 34m, 6.78m)  =>  (3353, 1238)

And time alone is the smallest part of the sum. At Brescia the system prudently recovered 55 per cent of the four items that are not hours, that is wrong lines and returns, half orders, lost customers and chasing: 148,000 euros a year times 55 per cent makes about 81,400 euros, that is 6.78 euros for each order of the year. Adding them, the threshold drops to about 1,240 orders a year, fewer than five per working day. With twelve thousand orders, in the Brescia case, the overall annual saving was worth about 129,000 euros, 5,700 of which went to maintenance. The custom piece, which cost 38,000 euros, paid for itself in about four months from going live, eight counting the four of the project.

The road I recommend in most cases is a mixed one: the accounting system you already have for records, items, stock and invoices, a portal for customers who reorder the same things, and a custom piece for what no product does well, that is reading messy orders, calculating the true promise and checking duplicates. If in the whole company orders are fewer than a thousand a year, you need neither: a shared inbox with rules, an order template for repeat customers and a weekly check of wrong lines are enough.

Whoever is weighing whether to take a package or have something custom built finds the broader reasoning in the article on business management software, off the shelf or custom, and the items a serious contract must contain in the one on custom software development.

The questions to ask whoever proposes a product

Five questions separate the products that solve the problem from those that move it.

What does it do with the email that is not a form? If the program can only receive already structured orders, it solves the 12 per cent of Brescia, not the 88. Ask to have it read three real orders, even ugly ones.

Does availability take committed goods into account? If the screen shows stock and nothing else, it promises you what you do not have. Ask for a test with an item already sold in full to other orders.

What happens when the same order arrives twice? If the answer is "the operator notices", there is no check. Ask to enter the same order twice and see what it says.

How does the order enter my accounting system? If every step is an export to do by hand, the data will come back scattered within a month.

How does my data come out? A product that does not expose the order history through a documented interface is another island, and your confirmation dates, your errors and your times are the last thing a company can afford to leave locked inside a supplier's program.

Artificial intelligence in order management software: where it helps and where it does not

Many products in 2026 promise an assistant based on artificial intelligence. I have used language models every day in my work since 2023, and for those who receive orders I have seen three uses that pay off and one that does not.

The draft of lines from the email. A model reads the customer's message, the file or the photo of the delivery note and prepares the lines: probable code, quantity, order reference, delivery address if different. A person checks and completes. The work of reading and rewriting, which took twelve minutes, becomes a check of four, and above all the order enters the list with the right fields instead of sitting in an inbox. Where the model is not sure of a code, it must say so, not choose.

The matching of an ambiguous code. "The usual three-quarter fitting" can match four items. The model proposes the two most likely by looking at that customer's history, and the person chooses. The cost is one click, and the advantage is that the choice is learned: the next time the system knows what that customer means.

The text of the confirmation and of the reminders. The model writes the message that goes with the confirmation, in the customer's tone and language, with references to the order. Quantities, prices and dates are those calculated by the system, not written by the model. The person reads and sends.

What does not pay off, and here I am clear, is the confirmation of availability and price. A language model does not know how many pieces are really free, how many are committed and when the truck will arrive. It does not know what discount that customer is entitled to this year. It can produce a plausible date, and a plausible wrong date is worse than no date, because the customer organises the site around it. Availability and price are calculated by the data with its rules, and if the data is not enough a person decides. The model prepares, the system calculates, the person decides.

There is a second limit, less visible. A model working on dirty data, that is with duplicate records, wrong stock and expired price lists, produces wrong proposals with great confidence, and people stop trusting it in a day. That is why artificial intelligence is added after the data, not before.

Mistakes to avoid when you change the way orders come in

I have seen the same script repeat in different companies, and it is worth knowing it beforehand.

Taking channels away from customers. The first impulse is to tell customers: from tomorrow order only from the portal. It works with ten per cent and annoys the other ninety. The system must take the order as it arrives, not ask the customer to change habits. The portal is proposed to those who always reorder the same things, and the rest are left to keep writing as they always have.

Automating before cleaning. A system that reads and enters orders by itself, with dirty records, produces errors faster than the office used to. First duplicate codes, packs and price lists of the main customers are fixed, then reading is switched on.

Promising a date you do not control. If the automatic confirmation contains a date the warehouse does not respect, the company has built a fast way of disappointing the customer. First you measure how true stock and committed goods are, then you publish the date.

Leaving the office out of the project. Whoever knows the customers and their ways of writing is the order office, not whoever develops. If it is not involved from the first two weeks, the system learns the wrong rules and people bypass it.

Measuring only speed. If the only thing you look at is how many orders are entered per hour, errors rise. Three things are measured together: the share retyped, the share right the first time and the confirmation time. If one improves and the others get worse, the system has moved the problem.

Forgetting the exceptions. The customer who has ordered by voice for twenty years, the urgency, the agreed replacement: these are the part of the trade the system must let happen. If there is no road for the exception, people will find it, outside the system.

Where to start: the first release in thirty days

Whether you choose a product, the accounting system module or a custom piece, the order in which things are done matters more than the choice. The plan I use for a company that receives orders from several channels begins with a first useful release in thirty days. It is not the complete system, which will take another three or four months: it is the part that starts taking work away from those who do it today.

First week: the measurement. The share of orders retyped, the share right the first time and the confirmation time are calculated, rebuilding channel and dates from mail and switchboard. Ten real orders are timed. The sum of the five items is redone. At the end there is a number, and a list of the orders with errors from the last three months, which usually shows at once the ten codes and the three customers where mistakes are made most.

Second week: the single list. A shared inbox with rules is opened, together with a three-field form for the phone, and agents are given one address to forward to. From that day every order has an arrival date, a channel and an owner. It is already an improvement, even without any new program, and measuring again at the end of the week shows how many orders were outside the list.

Third week: the checks. The three checks on lines are switched on, that is code, pack and customer's price, together with the flagging of duplicates. You start from the twenty customers who weigh the most. The people doing the work use them in parallel with today's method, and the results are compared order by order. This is the phase in which illusions are lost and trust is gained.

Fourth week: availability and confirmation. The promise is calculated with free stock, incoming goods and calendar, and the confirmation goes out with the date for the orders that pass all the checks. The others stay in the queue with the reason written down. At the end of the month the three numbers are measured again: it is the only way to know whether the project worked, and if not, to understand where to look.

The rest, from reading emails to the draft of lines, from the portal for repeat customers to the order status visible to the customer, comes later, when the data is reliable and the office trusts the system.

What to ask the person who builds it

If you choose the custom piece, three requests before starting. Ask that the three numbers, share retyped, right the first time and confirmation time, be calculated by the system from day one, so that the result is seen without a meeting. Ask that the rules, that is packs, customer prices, delivery preferences and the shipping cut-off time, can be changed by people working in the company, without going through whoever wrote the program. Ask that the data come out in an open format, so that you are not held hostage even by someone who did the job well.

If the number says it is not your problem

It may be that, once measured, the share of orders retyped is below 25 per cent, that your orders come out right the first time 98 per cent of the time and that the confirmation goes out the same day. It is good news, and it is worth saying clearly: in that case custom order management software is not what you need, and whoever tells you otherwise is selling you something.

In that case the bottleneck, if there is one, is almost always elsewhere. If you receive well but ship badly, the problem is in the warehouse and in logistics, and an order system does not solve it. If orders come out right but customers buy little, the problem is in the offer, the price or the relationship. If orders are few and large, thirty or forty a year worth hundreds of thousands of euros each, you do not need a system: you need a person who follows them one by one, like a project.

And there is a case in which software is not the answer even with bad numbers: when errors do not depend on the tools but on a record base never sorted out, with three codes for the same item and two files for the same customer. There the problem is the data, and a program helps only if you have cleaned it first.

If you have read this far, you probably have the Monday morning inbox in mind. Before looking at any demonstration, take the last fifty orders you received and write, for each one, which channel it came from, whether someone retyped it and how long it took to confirm. Then look at how many had a correction after confirmation. If more than half were retyped by someone, or more than one in ten had a correction, you already have the answer. The rest is a project, not a product choice.

If you want a second look at your case, the way is to get in touch, and when the right solution is a piece built around the way you work, the same page also covers custom software. For the method used to read the margin of a whole company, from above, there is the article on management control software.