AP Automation Controls: What Power Automate Does and Does Not Prove

Choose accounts payable automation software that keeps your chosen authorities separate: changing a supplier’s bank details, approving an invoice and releasing the payment. Those authorities may sit in different systems. An AP approval screen is not enough if an authorised user can change the beneficiary used by the bank through another route.

This article focuses on that boundary. It sets out the Microsoft functions supported by the available documentation and gives you acceptance scenarios for a wider product comparison. It does not rank AP products or compare subscription prices. The evidence available here is not sufficient to do either responsibly.

For broader approval design, see designing intelligent approval rails. For another use of repeatable software trials, see the inventory management comparison scorecard.

Definition: Separation of duties: allocating sensitive actions to different people or roles so that one person cannot complete a prohibited combination of actions without an independent check.

What can Power Automate contribute to an AP workflow?

Power Automate is a workflow layer. It is not evidence that the accounting system or bank enforces the same permissions. It may form part of an AP solution, but you need to assess its approval record alongside the actual supplier-record and payment controls.

Microsoft’s invoice-processing documentation, supplied on 08/11/2026, describes extracting invoice fields, including payment details. Its Power Automate approval guidance, supplied on the same date, describes an action that sends an approval request and waits for a response. Neither source establishes who can change the supplier’s bank details in a connected ledger or release a payment at a particular bank.

This matters when comparing an AP application with a workflow built around your existing systems. An application may provide its own supplier and approval screens; a Power Automate proposal may coordinate decisions around records held elsewhere. Either way, identify the system that holds the effective payment destination and every route that can change it. Do not assume that workflow approval controls an action performed outside that workflow.

Control matrix: documented Microsoft functions and remaining boundaries

The table maps the supplied Microsoft evidence to the three authorities in the buyer’s decision. It is not an end-to-end product certification. The final column identifies evidence gaps. It does not claim that a capability is absent from Power Automate, a connector or another system.

For a shortlist comparison, reproduce these rows for each named product and version in your own proposals. Attach vendor documentation, configuration evidence and trial results to each cell. A blank cell is not proof that the product has failed, and a sales assurance is not proof that the control is operating.

Definition: Compensating control: an additional check used to manage a risk when the preferred system restriction cannot be enforced. Its effectiveness depends on who performs it and whether it can be bypassed.

A documented reference point: invoice data is not payment authority

The following is an illustrative walkthrough, not a sandbox result or a claim about a particular customer configuration. Its inputs are a synthetic supplier invoice containing a proposed bank account, a Power Automate flow and an assigned invoice approver.

1. Extract the invoice. Microsoft documents that its invoice model can return payment details. The output is data from the document, not proof that the supplier authorised a bank change. See Microsoft’s model output documentation.
2. Request approval. Microsoft documents a Start and wait for an approval action. A flow can be configured to wait for all assigned approvers or for one response, depending on the chosen approval type. See Microsoft’s approval guidance.
3. Trace the unresolved boundary. The supplied documentation does not show that this approval checks a separately verified supplier account, prevents a direct ledger edit, or controls a bank upload. Those are separate acceptance questions for the proposed implementation.

Reader action: ask the implementer to show the record used as the authoritative supplier destination, the account used by the integration, and the bank instruction ultimately presented for release. If those cannot be connected to the approval evidence, the documented approval is useful but insufficient for this buying decision.

Three illustrative control scenarios

The following are synthetic scenarios and proposed acceptance criteria, not observed product results. Run them in a sandbox or other controlled environment with no live supplier details, bank instructions or funds. Record the actual result as pass, fail or not demonstrated.

Supplier change followed by an invoice

Illustrative inputs: Supplier SUP-A, an existing test account OLD, a requested replacement NEW, and users Change Maker, Invoice Approver and Payment Releaser.

1. Have Change Maker request NEW and attempt to make it effective without an independent check.
2. Have Invoice Approver approve an invoice for SUP-A.
3. Attempt to prepare and release a payment using NEW.

Expected result under the illustrative policy: the changed account cannot be used until a separate authorised person confirms it through an independently established supplier contact route. Invoice approval alone does not confirm the bank change. Capture the change request, confirmation, effective account and attempted payment destination.

A direct accounting-system edit

Illustrative inputs: the same supplier, with a user who can approve invoices but is not authorised to amend supplier bank details.

1. Sign in as Invoice Approver directly to the accounting system, rather than through the AP screen.
2. Attempt to replace OLD with NEW.
3. Inspect the supplier record and any audit or rejection evidence.

Expected result: the change is denied, or the stack applies an independently operated control that holds any payment using the changed details until verification. Under this illustrative policy, a warning without a hold is not a pass. If no evidence is available, record not demonstrated.

A changed payment after approval

Illustrative inputs: an approved test invoice for SUP-A, with OLD as the verified destination. Payment Releaser is a different person from Change Maker and Invoice Approver.

1. Prepare the payment and then attempt to alter the destination to NEW after invoice approval, including in any file or bank upload route.
2. Ask Payment Releaser to inspect the instruction before release.
3. Attempt release without independent verification of NEW.

Expected result: the altered destination is detected and held for verification, or the change is prevented. Evidence must connect the approved invoice, verified supplier destination, payment instruction and release decision. If the bank test environment cannot demonstrate this, the outcome is not demonstrated, not a pass.

Definition: Payment release: the authorisation that permits a payment instruction to proceed through the chosen banking route. It is distinct from approving the underlying invoice.

Scaling the controls without creating a bypass

A stack that works for a small finance team should also preserve separation when staff are absent, a new entity is added or an integration account is given broader access. Ask vendors to demonstrate those conditions in the proposed configuration. A role chart on its own is not enough.

What if the usual approver is away? A substitute should have a defined authority. If your policy prohibits the combination, they should not also be the person who made the supplier change or released the payment. Test the substitute’s actual access in every relevant system.

What if an administrator changes the workflow? Identify who can modify permissions, approval routing, integration credentials and payment settings. Decide who reviews those changes and where the evidence is kept. An administrator who can silently remove the restriction is a control dependency, not an ordinary approver.

Also inspect service accounts. An integration may legitimately need to perform actions that individual users cannot, but its access and configuration need separate oversight. A human approval recorded in one system does not by itself prove what the service account subsequently wrote elsewhere.

Definition: Audit trail: records that let an authorised reviewer reconstruct who requested, changed, approved and released a transaction, including relevant times and the destination used.

Trade-offs, risks and limitations

The strongest feasible separation may add licence, configuration and review costs. Manual supplier verification can be a practical compensating control, but it introduces a queue and depends on an independent reviewer having a trustworthy contact route. A documented procedure is weaker if payment can proceed before the reviewer completes it.

Integration is another trade-off. A workflow can make approvals visible while leaving a direct accounting edit or bank upload outside its reach. Even a well-documented approval event is incomplete evidence if it cannot be connected to the beneficiary actually used for payment.

The available Microsoft sources establish invoice extraction and approval functions, not the end-to-end controls of a particular deployment. No comparable product trials or subscription and implementation quotes are available for this article. A commercial comparison remains out of scope until providers quote the same control outcome, including integrations, testing and ongoing review.

When this recommendation does not apply

Do not select a candidate using this method if you cannot test the payment route you intend to use. A sandbox demonstration that excludes the accounting integration or bank handoff is useful preliminary evidence, but it is not an end-to-end acceptance result.

The same caution applies if your policy permits one person to hold more than one of these authorities. First specify the permitted combination and the independent check that makes it acceptable to your business. The illustrative three-person separation in this article is a proposed control, not a universal legal requirement.

If a vendor can demonstrate the restriction only by disabling a route your team must retain, the proposed setup does not meet your requirement. Either agree a documented alternative control and retest, or keep the candidate out of the final selection. Put an untested promise in the outstanding-evidence register, not the pass column.

Final verdict: choose the evidenced stack, not the feature list

No product wins on the available evidence. Power Automate is a candidate for an approval workflow, but the documented approval action and invoice model do not prove supplier-change and payment-release separation across a complete finance stack.

Select a stack when it passes your required scenarios across every system boundary, including direct edits and changed payment destinations, and when its written quote covers the controls you will operate. If a necessary control fails or remains untested, retain the existing controlled process while the gap is resolved.

What to explore next

• Discuss a bounded finance workflow → AI Automation Services
• Learn about the consultancy → About SIMARA AI
• Discuss your proposed control test → Contact SIMARA AI

For a separate estimate of document-handling and error costs, try the Document Processing Cost Calculator. It does not replace the control tests in this article.

Sources & Further Reading

• Microsoft Learn: Invoice processing prebuilt AI model, supplied 08/11/2026. Describes invoice and payment-detail outputs.
• Microsoft Learn: Use the invoice processing prebuilt model in Power Automate, supplied 08/11/2026. Describes using extracted invoice values in a flow.
• Microsoft Learn: Get started with approvals, supplied 08/11/2026. Describes approval actions, response options and the Dataverse approval environment.