Invoice Approval Software: Authority, Controls and Evidence

Most invoice approval projects are scoped as a routing problem. The team maps who signs what, configures a workflow, retires the email chain and reports a shorter cycle time. Twelve months later an auditor asks who approved a given invoice, on what authority, against which coded amount, and whether that person could also have created the vendor. The workflow answers the first question and struggles with the rest.

That gap is a design choice, not a product defect. Approval software enforces whatever authority model you give it, including a weak one: Microsoft documents that the Dynamics 365 Finance setting preventing a submitter from approving their own document is off unless someone turns it on. The routing works either way. Only one configuration produces evidence a reviewer can rely on. This guide covers the approval layer specifically: the authority matrix, coding, budget checks, segregation of duties, exceptions, mobile approval, evidence and ERP integration.

What invoice approval software controls

Invoice approval software routes a supplier invoice to the people authorized to commit the organization to paying it, records their decision against a specific version of that invoice, and releases it for posting once the required decisions exist. It sits between validation and posting. It does not read the invoice, and it does not decide whether the invoice agrees with the purchase order.

If extraction is the constraint, the relevant test is extraction accuracy on a representative invoice set, not approval configuration. If the whole function is in scope, the question is broader than this article and belongs with comparing complete AP platforms. For how approval fits alongside capture, matching, exceptions and posting as one sequence of gates, see the wider invoice automation control map.

Design the approval matrix before configuring a tool

A delegation-of-authority matrix states who may commit the organization to what, and on what basis. It is a governance artifact owned by finance leadership, approved by the board or its delegate, and versioned with an effective date. Software configuration translates that document. Building the matrix inside a vendor configuration screen produces an authority model nobody formally approved.

Check the defaults you inherit. Oracle’s predefined Payables approval rules approve invoices under 1,000 automatically and route those at or above it to the requester’s immediate supervisor. That is a reasonable demonstration and a poor policy for most organizations, because it assumes one currency, one threshold and a supervisory hierarchy that matches budget ownership. Treat every predefined rule as a placeholder.

Thresholds also have to be transaction-specific. The amount a manager may commit at requisition, when the spend is still avoidable, is a different question from the amount they may approve at invoice, when the goods have already been received. Set those separately and record why they differ.

Fix coding before approval, not after

An approver confirms that a charge is legitimate, correctly attributed and within their authority. They cannot confirm attribution while the account, cost center, department, project and tax treatment are still open, and the approval means little if accounts payable recodes the invoice afterwards.

Decide explicitly who owns coding. When the requester or budget owner codes, accuracy is usually higher because they know what the spend was for, but throughput depends on people whose main job is elsewhere. When accounts payable codes, throughput is predictable but attribution errors surface late, often at month end. A workable split is accounts payable proposing coding from the purchase order or supplier defaults, and the approver confirming or correcting it in the approval step, with any change recorded.

Derived coding needs the same scrutiny. Microsoft’s vendor invoice documentation states that for invoices tied to a purchase order the default financial dimension comes from the purchase order lines, while for invoices with none the dimensions merge from the dimension link, invoice header and item in a defined priority order. Those are the invoices where coding errors concentrate and where the approver is often the only control. Tax and reporting flags belong in the same step, because a misclassified reportable payment gets corrected at year end under time pressure, if at all.

Check commitment and budget at the invoice, not just at intake

Budget control is strongest before money is committed, which is why requisition-stage approval and funds reservation carry most of the weight. By the time an invoice arrives, the goods or services are usually received and the commitment is real. The invoice-stage question is narrower: does this invoice agree with what was already authorized, and what changed?

Three checks belong here. First, consumption against the original commitment, so an approver can see that a 50,000 purchase order has already absorbed 47,000 of invoices before approving a further 6,000. Second, whether the invoice covers something the commitment never included, the usual route for scope creep on services. Third, whether the coding still points at the budget line originally approved.

Where no commitment exists, the approval step is the only budget control, and those invoices most deserve a lower threshold, a second approver, or both. Understanding how the commitment was created upstream tells you how much reliance the invoice-stage check can place on it. Timing matters too: an invoice sitting in a queue at period end is still an expense of the period the goods were received, so the close has to accrue what has not been approved rather than wait.

Make segregation of duties enforceable in the tool

The 2025 revision of the GAO Green Book, which supersedes the 2014 edition and takes effect from fiscal year 2026, states the requirement plainly. Management considers segregation of duties in designing control activities “so that incompatible duties are segregated,” and where such segregation is not practical, “management designs alternative control activities to mitigate the risk.” The duties being separated are authorizing transactions, processing and recording them, reviewing them, and handling any related assets, “so that no one individual controls all key aspects of a transaction or event.”

Test the configuration rather than the feature list. In Dynamics 365 Finance the setting is Disallow approval by submitter, and Microsoft’s approval process guidance states that “by default, this setting is No, and users can approve the document if they’re included in the approval step’s assignment settings.” A separate final approver option exists to require extra approval “when the user who submitted the document also approves it.” Neither is on by default. A platform can hold a defensible authority matrix and still permit self-approval because nobody changed a switch.

Some products state the constraint as a property rather than a setting. ApprovalMax describes requester and approver as “separate by design, enforced by the system rather than trust.” That is a claim to test rather than accept, because what matters is whether the separation survives delegation, substitution and administrator override.

Small teams cannot always separate all four duties, and the Green Book anticipates this: where segregation is not practical “because of limited personnel or other factors, management designs alternative control activities to mitigate the risk.” That usually means review of payments above a low threshold by someone outside accounts payable, independent review of bank detail changes, and a periodic sample test of approvals against the matrix. What is not defensible is treating headcount as a reason to record no control at all.

Route exceptions to the person who can clear them

An exception queue that routes everything to accounts payable moves work without resolving it. Accounts payable can correct a keying error; it cannot decide whether a price increase was agreed, a service was delivered, or an unbudgeted charge should stand. Route each exception type to the role that holds the answer.

The NetSuite three-way match approval workflow shows how granular this can get, documenting separate states for bill validation, quantity tolerance, quantity difference and amount validation before a bill routes to an approver or is approved automatically, with a view listing every identified discrepancy. Exceptions are typed, not pooled.

A workable taxonomy separates at least six conditions: no purchase order where one was required; a price or quantity variance escalated from matching; a missing or partial receipt; a coding dispute; an amount above the approver limit; and a suspected duplicate. Each needs a named owner, an expected resolution time and a defined route back.

Automatic escalation deserves particular care. Microsoft documents that a workflow can set a time limit and that “if the time limit is exceeded, the system acts on the document,” with the action configurable. Escalating an aged invoice to a senior approver is reasonable; configuring the timeout action as approval turns a control into a delay counter, and the trail will show an approval nobody made. Measure the queue by aging and exception type, because a rising share of one type points upstream.

Mobile and delegated approval without weakening the control

Mobile approval is a real improvement when it shortens the time an obligation sits unreviewed, and a real weakness when it reduces the decision to a button. The test is what the approver sees before deciding: supplier, amount, coding, the purchase order or receipt reference, any variance, and the invoice image. If the view omits the coding or the image, the approval is a routing acknowledgement. Bulk approval is the sharpest version of the same problem, and is worth restricting by amount and exception status.

Delegation needs a start date, an end date and a named delegate who is themselves within authority, because open-ended delegation quietly becomes the operating model. Where a product offers substitution, check whether the substitute inherits the original approver limit or applies their own; inheriting a higher limit is an authority breach no report will flag.

Email approval carries a specific fraud exposure. The FBI’s 2025 Internet Crime Report records 1,008,597 complaints and 20.877 billion dollars in reported losses, with business email compromise the second largest loss category after investment fraud. It defines business email compromise as a scam “targeting businesses or individuals working with suppliers and/or businesses regularly performing wire transfer payments.” An approval transmitted by email, from an account an attacker may control, is precisely that target. Record approvals in an authenticated session and use email for notification only.

Make the approval trail admissible evidence

An approval record has to answer four questions: who approved, on what authority, when, and what exactly they approved. The fourth is handled worst by most systems, because an invoice can change after approval. Binding the decision to a version is what makes the record meaningful.

Electronic approval is legally durable. Under the ESIGN Act a record or signature “may not be denied legal effect, validity, or enforceability solely because it is in electronic form,” and the retention requirement is met where the electronic record “accurately reflects the information” and “remains accessible to all persons who are entitled to access” in a form “capable of being accurately reproduced for later reference.” The statute is about accessibility and integrity rather than file format.

Tax retention imposes concrete requirements. IRS Rev. Proc. 97-22 requires an electronic storage system to “index, store, preserve, retrieve, and reproduce” the books and records, with “reasonable controls to prevent and detect the unauthorized creation of, addition to, alteration of, deletion of, or deterioration of electronically stored books and records.” It also requires storage in a manner “that provides an audit trail between the general ledger and the source document.” A retained approval that cannot be tied back to a ledger entry fails that test.

Auditors exercise the trail directly. PCAOB AS 2201 describes a walkthrough as following “a transaction from origination through the company’s processes, including information systems, until it is reflected in the company’s financial records,” and requires the auditor to evaluate “whether the person performing the control possesses the necessary authority and competence to perform the control effectively.” That is a question about your authority matrix, answered out of your approval records. Before signing, confirm that overrides and force approvals are logged as distinct events carrying a reason, that the trail exports independently of the vendor, and that it survives the full retention period.

Integrate so the approval is the system of record

The most common integration failure is a quiet one. Approval state lives in the approval tool, accounting state lives in the ERP, and the two drift apart. An invoice shows as approved in one system and unposted in the other, and neither is wrong about itself.

Decide where approval state is authoritative and make everything else a view of it. Four data flows have to be reliable in both directions: the supplier master, so approvals cannot be granted against a payee the ERP does not recognize; open purchase orders and receipts, so commitment checks use current data; the chart of accounts and dimension values, so coding posts without translation; and the entity structure, so limits apply per entity.

Test refresh behavior, because a platform copying purchase order data overnight shows an approver a commitment position a day old. Record whether integration is live, cached or batch; which system owns which record is the broader question handled in the finance systems integration map. Multi-entity organizations should confirm that limits, currencies and hierarchies are set per entity, that authority in one entity is not inherited elsewhere, and that failure modes behave sensibly when the ERP is unavailable or posting fails after approval.

Representative invoice approval tooling checked 21 August 2026

Products were included when official documentation checked on 21 August 2026 evidenced approval routing rules, some form of threshold or limit, and an approval trail. Extraction-only and procurement-only products were excluded, as were pages describing collaboration or general document workflow without documented approval mechanics. Stampli and AvidXchange both rank on the United States results page for this term, but the pages surveyed describe an approval workspace and general document workflow rather than documented routing, limit or trail behavior, so they are not in the table. That is an observation about public documentation, not product quality.

The table is not a ranking. Products are grouped by operating model and alphabetized within each group. Official pages establish company-stated availability only, not comparative control effectiveness or performance on another organization’s invoices. Pricing is reported as structure, not negotiated cost.

Implement in a sequence that keeps the control provable

Sequence the rollout so the authority model is proven before automation scales. Approve and date the matrix first, then configure it, test it and extend it. Reversing that order produces a fast process nobody can evidence. Start with one entity and one category, choosing a population with enough exceptions and enough invoices without purchase orders to be representative, because a pilot on clean purchase order invoices proves very little.

Run negative tests explicitly, not only the intended path. Attempt a self-approval. Submit an invoice above the approver limit. Submit the same invoice number twice. Delegate to someone with a lower limit and try to approve above it. Let an invoice breach its time limit and confirm what the system does. Each should fail in a specific, logged way, and that log is what you show an auditor.

Measure five things after go-live: the share approved without manual intervention, cycle time by threshold tier, exception rate by type, queue aging, and the rework rate where coding changed after approval. The last is the measure most teams skip, and the clearest signal that coding is settled in the wrong place. Before extending to further entities, re-run the negative tests, because authority models drift as people change roles.