Purchase approvals: what was approved before the change?

The approval covers the purchase the manager saw

Say maintenance needs a specific part. The request names supplier A, and the manager approves the purchase. Later it turns out that A cannot deliver the part. The buyer changes the supplier to B. At this company, such a change needs approval again, under its own rules.

If the buyer just overwrites the name in the form, the earlier “approved” may stay next to the new supplier. The next person then has to work out whether the manager has already seen the proposal to buy from B. The date of the last edit alone does not explain what the decision covered.

In the proposed solution, the original request stays available with the manager's approval. The buyer prepares the changed version, and the manager gets a short explanation:

Supplier changed from A to B. Supplier A cannot deliver the part. The earlier approval covered buying from A; buying from B is waiting for re-approval.

With this note, the manager opens the new version and can compare it with the previous one. They do not have to search the correspondence for why the matter came back. Once they decide, the record of the decision stays with the version they just reviewed. The buyer and finance see both the earlier agreement and the answer on the change.

Why the team keeps rebuilding the same story

Chat is good for a short question, a form for collecting data and an ordering system for running the order. The trouble starts when an approval in one place does not clearly point to the content recorded in another. The buyer remembers the change, the manager remembers the original purchase, and the person preparing the order sees only the current form.

Joining this information up should let an employee open the approved request from wherever they do the next piece of work. Next to the current proposal they need to see what changed and whether someone has already approved that change. Handing the matter to a colleague then needs no separate story of every step.

Preparing material before a decision is covered separately by the offer for AI in procurement: comparing terms and collecting questions for suppliers. The company sets which changes have to go back to the manager. In the example it is a change of supplier; your process may have other rules. The supplier builds these arrangements into the app. Keeping the version and the approval together can be solved with ordinary software, with no AI in the decision.

First check what your current ordering system can do

Ordering systems can send requisitions for review as whole documents or as single lines, and create a purchase order after approval. How a later change of supplier is handled has to be checked in the solution you use and its configuration.

Ask the person responsible for the ordering system to walk through the case above with the buyer. If the system keeps the approved request, shows the change and lets you send it back to the right person, configuring the current flow may be enough. Then consider whether the extra form and separate approvals in chat are still needed.

An integration makes sense when the tools in use handle their own parts of the work well, but lose the link between the request and the decision. Your own app is worth considering when the team needs a shared view of changes and approvals that the current tools cannot provide comfortably. You can limit the project to that part and leave orders and accounting records in the ordering and finance systems.

Moving to the new purchase approval flow without losing earlier agreements

At launch, you have to decide what happens to requests already in progress. Some can finish the flow in the old tool, and selected matters can be moved with their attachments and decision history. Importing the current form content alone will not show what the manager approved before the change. The person responsible for purchasing should confirm that the earlier decision still points to the right version of the request.

The offer should cover later support for the connection to the ordering system: who deals with an approved request that does not appear where the work continues, and how to report a problem. Also settle access to the code and documentation, and exporting requests with their decisions and attachments. These arrangements matter when you change supplier.

When replacing the tool for collecting documents from suppliers, the guide to a custom supplier portal in place of SaaS will also help.

What you can order from Syntalith

Syntalith builds custom software and integrations. For this problem we propose linking the register of requests to the place where purchasing carries on the work, plus a view showing the approved version and later changes. The first scope can be limited to one type of purchase.

Your team brings the rules for re-approval and knowledge of the current flow. In the conversation we will settle whether you need configuration of the ordering system, a connection between existing tools, or also your own screen for comparing requests. Tell us about the last change where you had to find the earlier approval, and show where the request and the decision were recorded. Syntalith's apps start from €3,000 net, and we set the scope after a free process review (pricing).

When the difficulty already starts with comparing offers, look at the possible AI rollouts for purchasing. They help separate work on documents from the purchase approval flow.

What a purchase approval system costs and when it pays back

Where to start

In the free process review we choose one process and count the team's volume and working time, and within 2 working days you get a written summary with a price. We build as part of AI apps, and we price maintenance separately.