Power Platform

How a Finance Team Can Automate Their Payment Approval Process and Build a Full Audit Trail

#Power Platform#Power Automate#Power Apps#SharePoint#Finance#Approval Process#Audit Trail#Business Automation
How a Finance Team Can Automate Their Payment Approval Process and Build a Full Audit Trail

How a Finance Team Can Automate Their Payment Approval Process and Build a Full Audit Trail

If you have ever had to track down who approved a payment by digging through emails, this is for you.

Most finance teams run their approval process the same way. Someone sends an email. It gets forwarded. Someone replies to the wrong thread. Documents get attached, re-attached, and lost. By the time the payment goes through, nobody has a clean record of who approved it, when, or why.
There is a better way to handle this and you can build it using Power Apps, Power Automate, and SharePoint.

Who Uses This System

Before getting into the build, it helps to understand the two types of users and what each one can do.

A Submitter is a member of the finance team who initiates a payment request. They fill in the details, select an approver, upload supporting documents, and submit. Once submitted, their job is done until the request is resolved. They cannot approve their own request, they cannot change the approver after submission, and they cannot edit the record while it is in review. The one thing they return to do is enter the journal number once the payment has been approved and processed.

An Approver is someone with the authority to review and approve or reject payment requests. They receive a notification when a request is assigned to them, review the details and documents, and make a decision. If they believe the request should be handled by a different approver, they can reassign it, and that reassignment is tracked. They cannot submit requests themselves.

This separation is not just about user experience. It is about control, accountability, and making sure no single person can both initiate and approve a payment.

The Security Model

The app is shared only with the people who are supposed to use it, nobody else can open it. But sharing alone is not enough. Inside the app, what each person sees and can do is controlled by their role.

Two SharePoint lists act as the role registry, a Submitters list and an Approvers list. Each list holds the names and email addresses of the people in that role. When someone opens the app, it checks which list they appear in and routes them to the right experience automatically.

A submitter who navigates to the approval area will find the approve and reject buttons are simply not there for a submitted approval. An approver who opens the app goes directly to their review queue, not the submission form. The buttons, screens, and actions available to each person are determined entirely by their role enforced through Power Fx formulas that check the users against the appropriate list.
The security is not a setting someone can accidentally change. It is built into the logic of the app itself.

What the Submitter Does

When a submitter opens the app they land on the submission screen. They fill in the payment details, amount, description, payment reference, and any relevant notes. They then select an approver from a dropdown that pulls from the Approvers list, so they can only ever assign to a legitimate approver. They can also attach multiple supporting documents directly in the app. Invoices, purchase orders, contracts, anything relevant to the payment can be uploaded at this stage. These documents do not just sit loosely. Power Automate handles them properly, which we will come to shortly. Once they hit submit, the record is locked. They cannot edit it, they cannot change the approver, and they cannot approve it themselves. Their role in the process is complete until a decision is made.

What Happens in the Background - Power Automate

This is where the real work happens, invisibly, every time a request is submitted. Document management, each payment request gets its own folder automatically created in a SharePoint Document Library. The documents the submitter uploaded are saved into that folder, a link to the folder is generated, and that link is attached to the SharePoint list record. Every request has its documents in one place, permanently linked to the record, accessible to anyone with the right access. No attachments floating around in emails. Approver notification, the assigned approver receives an email containing the payment details, the attachments so they can review everything, and a link back to the specific record in the Canvas App. Clicking that link opens the app directly on that request, no searching, no navigating, straight to the record that needs their attention.

What the Approver Does

The approver clicks the link in their email and lands directly on the approval screen for that specific request. They can see all the details the submitter entered, and make a decision. If they approve, they confirm and the flow takes care of the rest. If they reject, they must enter a comment before the reject button becomes active. The button stays greyed out until something is written. There is always a documented reason for every rejection, for the submitter and for the audit record.

Reassignment: if the approver determines the request should be handled by someone else, they can reassign it to another approver from within the app. This reassignment is logged automatically, who it was originally assigned to, who reassigned it, who it was reassigned to, and when. The new approver receives their own notification email with the same details and link to the App. The audit trail captures every hand the request passed through, not just the final decision.
A submitter cannot do any of this. Once they have submitted, the reassignment option is not available to them.

It is also worth noting that approvers can only act on requests that are assigned to them. If an approver opens the app and navigates to a record where they are not the designated approver, the approve and reject buttons are not available to them. They can see the record but they cannot action it. This ensures that no approver can step in and approve a payment that was never theirs to review.

After the Decision

If approved, the submitter receives an email telling them the request has been approved, who approved it, and a link back to the record in the app. They open the app, navigate to that record, and enter the journal number for the processed payment. This final step closes the loop, the record now has the journal number attached, making it easy to cross-reference against the finance system.

If rejected, the submitter receives an email containing the approver’s comment explaining exactly what needs to change. When they open the app and return to that record, they can see the rejection reason directly on screen, update the relevant details or swap out documents, and resubmit. The resubmission triggers the flow again, the approver is notified, and the process continues from the review stage. The original submission, the rejection reason, and the resubmission are all captured in the audit trail so the full history of that request is always visible.

The Audit Trail

Every meaningful action is captured automatically, nobody has to remember to log anything: Who submitted the request and when

Which approver it was originally assigned to

Any reassignments, including who made them and when

Whether it was approved or rejected, by whom, and when

Rejection comments

The journal number entered after approval

The folder to the link of every document associated with a request

All of this sits in SharePoint. When an auditor asks who approved a specific payment six months ago, the answer is a filter and a click.

Why This Works

This solution holds up in a real finance environment because it does not rely on people remembering to do the right thing. Documents are saved automatically. Audit entries are written automatically. Role restrictions are applied automatically. The approver cannot skip a rejection reason. The submitter cannot approve their own work. It is built around how a finance team actually operates, with the controls that compliance and audit require baked in from the start, not bolted on afterwards.

If your team is still managing payment approvals over email, this is a straightforward place to start. You likely already have the Microsoft 365 tools you need.


---

What did you think of this post? Let me know on Twitter or LinkedIn!