Purchase approvals: what was approved before the change?

Approval belongs to the request the manager saw

Suppose maintenance needs a specific replacement part. It submits a request naming supplier A, and the manager approves the purchase. Later, supplier A cannot deliver the part, so the buyer changes the supplier to B. This company's own policy requires another approval when the supplier changes.

If the buyer simply overwrites the name in the form, the earlier “approved” label may remain beside the new supplier. The next person then has to establish whether the manager has seen the proposal to buy from B. The date of the last edit does not explain what the manager approved.

In the proposed solution, the original request remains available with the manager's approval. The buyer prepares a revised version, and the manager receives a short explanation:

Supplier changed from A to B. Supplier A cannot deliver the part. The previous approval covered the purchase from A; the proposed purchase from B is awaiting another approval.

Alongside this explanation, the manager can open the revised request and compare it with the earlier version. They do not have to search the correspondence to find out why the request is back. Their new decision stays with the version they reviewed. Procurement and finance can see both the earlier agreement and the response to the change.

Why colleagues keep reconstructing the same history

Chat works well for a quick question, a form collects information, and the ERP handles purchase orders. The difficulty arises when approval in one place does not clearly identify the request in another. The buyer remembers the change, the manager remembers the original purchase, and the person preparing the order sees only the current form.

Connecting that information should let an employee open the approved request from wherever they continue the work. Beside the current proposal, they need to see what changed and whether someone has approved it. A colleague taking over can then follow the request without a separate explanation of every step.

The company decides which changes need to go back to the manager. In this example, it is a supplier change; your process may use different rules. The developer reflects those decisions in the application. Preserving versions and approvals can be handled with ordinary software, without adding AI to the approval decision.

Start with the ERP you already use

Microsoft's Dynamics 365 documentation describes routing purchase requisitions for review as whole documents or individual lines. A purchase order can follow approval. How a later supplier change is handled needs to be checked in the system and configuration you use.

Ask the person responsible for your ERP to walk through this case with a buyer. If it preserves the approved request, shows the change, and lets the team send it back to the right person, configuring the existing workflow may be enough. It is then worth asking whether the extra form and separate chat approvals are still needed.

An integration fits when the tools handle their parts of the work well but lose the connection between the request and the decision. A custom application is worth considering when the team needs a shared view of changes and approvals that the current tools cannot readily provide. The project can stay focused on that gap while purchase orders and accounting records remain in the ERP.

Moving to a new workflow without losing earlier decisions

At launch, the team needs to decide what happens to requests already in progress. Some can finish in the old tool, while selected requests move with their attachments and decision history. Importing only the current form will not show what the manager approved before a change. The procurement owner should confirm that each earlier decision still points to the correct request version.

The proposal should also cover maintenance of the ERP connection: who handles a request that has been approved but does not appear where the team continues its work, and how staff report the problem. Agree on access to code and documentation, along with exporting requests, decisions, and attachments together. Those arrangements matter if another provider takes over.

If you are also replacing a tool for collecting supplier documents, the guide to a custom supplier portal instead of SaaS covers useful questions about that transition.

What to commission from Syntalith

Syntalith builds custom software and integrations. For this problem, we propose connecting the request register to the place where procurement continues its work, with a view showing the approved version and subsequent changes. The first scope can cover one type of purchase.

Your team supplies the reapproval rules and knowledge of the current workflow. The initial discussion establishes whether the work calls for ERP configuration, connections between existing tools, or a custom screen for comparing requests. Describe the last change that made someone search for an earlier approval, and where the request and decision were recorded. See Syntalith's pricing for service information.