We bring together in a single chain where a request came from, which quotes were obtained, who approved what, and whether the invoice that arrives matches the order. Procurement runs in the system rather than in people's memories; every step can be read back afterwards along with its reasoning. Your existing ERP stays where it is.
Procurement is the last place software reaches in most businesses. A request starts with a phone call or a message from production. The quotes obtained pile up in an email inbox, sometimes on paper. Approval is the 'fine' the manager says in the corridor. The order is placed, the goods arrive, the invoice lands with accounting. Every link in the chain works on its own but leaves no trace behind it. Six months later there is no corporate answer to the question 'who did we buy this material from, at what price and why from that firm'; the only person who knows the answer is the person who made the purchase. This is not a matter of bad faith; it is the natural result of a process built in a way that keeps no record anywhere.
In enterprise software literature this area is called a procurement management system, usually shortened to PMS. Whatever it is called, the problem it solves is the same: who raised the request, which quotes were collected, who approved it and on what basis, and whether the incoming invoice matches the order — none of this sits in a single record. Once that information is scattered across email, WhatsApp and desk-side conversations, procurement stops being auditable.
The purchasing module in an ERP usually holds the second half of the chain: the order is recorded, goods receipt is entered, the invoice is processed. The first half — how the request arose, how many suppliers were asked for a quote, on what basis the quotes received were compared and who gave the approval — stays outside the system in most installations. That part consists of email, Excel and verbal approval. On top of that, whether the order, the goods receipt and the invoice agree with one another is usually checked by hand; in a busy month end that check is not made in practice. Price differences, short deliveries and invoices paid twice come from here. And when something goes wrong it is nobody's fault; the information needed for the check was never on one screen.
The system we build runs this chain end to end in one place. A request is opened with a form; the person raising it, the date it is needed, the budget line and the reason are put on record. When the request is approved it moves to the request for quotation (RFQ) step; the same line list goes to several suppliers with identical content. The quotes received are compared not on price alone but with lead time, payment terms, freight and any past performance visible together. The choice is recorded with its reasoning, the approval goes to the relevant person according to the value threshold, and the purchase order is created. When the goods arrive a receipt record is entered; partial deliveries and rejections are handled separately. In the final step the order, the goods receipt and the invoice are compared automatically; this is called three-way matching (3-way match), and the lines that do not agree are listed before payment.
The realistic limit of this work is as follows: the software does not negotiate and does not reduce procurement costs by itself. What brings the price down is genuinely obtaining several quotes, consolidating scattered small purchases and having data in hand when talking to a supplier; the system makes these possible and easy, it does not replace them. The second limit concerns the design of approvals. If the approval chain is set up more rigidly than necessary, people bypass the system: urgent purchases are made by phone, the record is entered afterwards and the process exists only on paper. That is why we define value thresholds, delegation and the route for urgent purchases together from the start. An approval workflow that is not used is more harmful than one that was never built, because it creates the illusion that the records are correct.
Companies where a single person runs all buying. This structure works quickly but cannot be handed over: when that person goes on leave or leaves the company, what was discussed with which supplier, which price is valid and the status of open orders does not stay with the organisation. The first gain here is not cost but the knowledge passing to the company.
Plants buying hundreds of small-value lines a month. Individually these purchases look unimportant, together they add up to a serious sum, and none of them is properly tracked. Collecting requests on a form makes it possible to combine repeating lines into a single order. The same material being bought separately by different departments also becomes visible at this stage.
Companies where spending authority varies by value and by subject, and where senior management approval is required above certain thresholds. In these structures the real problem is not the approval itself but not knowing where it is waiting. Once the authority matrix and delegation are defined, the list of pending items becomes visible and reminders go out automatically.
Businesses that go through independent audit, ISO certification or customer audits. These audits ask for the reasoning behind a purchase decision, the quotes obtained and the approval trail. When the process runs on email these proofs have to be assembled after the fact; when it runs in the system they are already there. Invoice matching records also shorten reconciliation periods noticeably.
A purchase request is opened with a form rather than a free-text message: what, how much, when and for which job. The moment the request is opened, the stock on hand in the warehouse and any open order are shown; if the same material is already in transit, the requester sees it. Once the budget line is linked, the spend can be read against the budget before it is even committed.
The same line list is sent to the selected suppliers with identical content; who was asked, when, and who replied is on record. When a quote arrives as an email attachment it is attached to the record as well. In this way 'we took three quotes' stops being a habit and becomes a step that can be evidenced.
The quotes received are placed side by side in a single table: unit price, total, lead time, payment terms, freight and currency. The cheapest quote is not automatically the winner; when the choice is made the reasoning is written down and stays on the record. For quotes in different currencies a comparison converted to a common currency is also shown.
Who approves what is defined in an authority matrix by value, category and cost centre. Anything above a given value escalates to the next level. When an approver is on leave, delegation takes over so the process does not stall on one person. Pending approvals receive reminders, and how long each has been waiting is shown plainly in the list.
An approved quote becomes a purchase order in a single step; the order is sent to the supplier and the confirmed date is recorded. Orders approaching and past their due date are listed separately. On partial deliveries, how much of the order has been closed is tracked, and the open balance stays visible and is not forgotten. Order revisions are also kept as versions.
Incoming goods are received against the order; quantity differences, short deliveries and quality rejections are handled separately. A rejected line is tracked as a return or a re-delivery. The receipt record feeds both the warehouse entry and the invoice match, so the same information is not entered twice and no difference arises between the two records.
The order, the goods receipt note and the invoice received are compared automatically on quantity and price. If all three agree, the invoice is treated as ready for payment; if not, the difference is listed with its reason and goes to the relevant person before payment. Duplicate invoices, lines that were never ordered and price deviations are caught at this step.
We write down step by step how a request arises today, how a quote is obtained, who holds the approval and how the invoice is checked. The exceptions go on record too: urgent purchases, single-supplier lines, work that requires an advance payment. The scope comes out of this map. This stage usually takes one to two weeks.
Which value is approved by whom, which rule applies in which category and how delegation takes over are clarified in writing. This is a management decision, not a technical one, and it is the most critical point of the project; the decision taken here directly determines whether the system is usable day to day.
The request form, request for quotation, comparison table, approval workflow and order steps are developed; a working piece is shown at the end of each sprint. The supplier list and material records are read from the existing ERP rather than entered again. Scope varies, but in most installations this part takes four to eight weeks.
The warehouse entry, partial delivery and rejection flows go live; three-way matching is then connected to the accounting side. Who unmatched lines go to and how they are closed is decided together. Tolerance limits are also defined at this stage. This step cannot be set up correctly without the accounting team taking part.
The system is first piloted in a single category or a single department; the old method runs in parallel for a while. Once the results are verified, the scope is widened step by step. At handover, how the authority matrix is to be updated is left in writing. Training covers not only the procurement team but also the departments that raise requests.
The difference is which half of the chain is on record. ERP modules usually hold everything from the order onwards well; how the request arose, the request for quotation, the comparison and the approval step stay in email in most installations. We build this missing first half and connect it to the order, account and stock side of your existing ERP. We do not switch your module off; we give it a properly fed input.
We do not make it a condition. In practice most suppliers send their quote by email, usually as a PDF or an Excel file; the system accepts this and attaches it to the quote record. A portal can be opened for suppliers who want one, but making it compulsory slows the process down rather than speeding it up, especially with small suppliers. The portal decision is taken supplier by supplier, according to how continuous the relationship is.
Not directly, and we do not promise that. Software does not negotiate, does not persuade a supplier and does not change a price list. What it does is make the behaviours that can bring the price down possible: genuinely obtaining several quotes, combining scattered small purchases, having the past price and the supplier's performance to hand at the moment of the conversation. Those behaviours come from your team; the system only removes the obstacle in front of them.
If it is badly designed it will; that is a real risk. This is why we tie approval not to every purchase but to value and category thresholds: low-value routine purchases pass in a single step, larger amounts escalate. Delegation is defined, so the process does not stall on someone who is away. A separate route is left for urgent purchases and is put on record afterwards. The aim is not to slow the work down but to make the waiting visible.
Three-way matching (3-way match) checks, before an invoice is paid, whether three records agree with one another: the purchase order placed, the delivery note showing that the goods were actually received, and the invoice received. If the quantity and unit price are the same in all three, the invoice is treated as ready for payment; if not, the difference is listed with its reason. Done by hand, this check is skipped in busy periods. Done automatically, duplicate invoices and lines that were never ordered are caught before payment.
A request process opened with a form and checked against stock and budget; request for quotation and a comparison table; an approval workflow driven by value and category, together with delegation; order and lead time tracking; goods receipt including partial deliveries and rejections; three-way matching and a list of invoice differences; an audit log of every step. Everything is yours, including the source code, the database and the purchase history that accumulates.
In a 30-minute discovery call we listen to what you need and tell you honestly whether custom development or an off-the-shelf product is the better answer.
We bring together in one record who the supplier is, when each of its documents expires, how well it kept to its delivery dates last year and which price agreement is in force. The approved supplier list stops being an Excel file. A supplier portal connects to the same structure as an option.
Details →We build a layer that plans the shipment, assigns the vehicle and the route, compares carriers and freight rates, issues the e-waybill and collects proof of delivery from the field. If you run your own fleet, fuel, maintenance and document costs accumulate in the same system; if you work with hauliers, a record is kept of which job went to whom and at what price.
Details →We gather orders from your e-commerce site, marketplaces, the B2B dealer portal, the showroom and the telephone into a single pool. Stock is promised from one source rather than divided up channel by channel; the allocated quantity comes off it, and cancellations and returns come back into it. The aim is not to sell the same item twice, and to see where an order stands from a single screen.
Details →We gather all of a product's attributes, descriptions and translated texts in one centre, and produce the enriched version for each sales channel's own template from there. A field that is missing or breaks a rule is caught before the product goes out to the channel. Product data no longer lives in a file on somebody's desktop.
Details →We bring photographs, video, catalogues and design files together in a single archive, and record which product each file belongs to, which version is approved and where it may be used. The sizes and formats each channel asks for are derived automatically from the original, so nobody spends their time resizing files.
Details →We bring the store's till, stock, promotions and shift handover together in a single system. The POS here is not the virtual POS on your website; it is the real till on the counter. In multi-branch structures, prices and promotions are managed centrally and the day closes with the same discipline in every branch.
Details →
