Research · Published:
Did invoice approval occur before delegation expired?
A time-aware study of delegated invoice authority, workflow events, amount thresholds, and superseding decisions.
Methodology
An invoice can display “approved” even when the business authority behind that status is uncertain. A delegate may have approved moments after a temporary assignment expired, the invoice may have crossed a threshold after tax or currency conversion, or a workflow may have recorded action after the delegator returned. This study asks how to reconstruct authority at the precise time of approval. The method does not decide that an approval is legally valid, infer intent, extend a delegation, change a workflow record, accept an invoice, approve an exception, or release payment. Its output is a time-aware evidence packet connecting the invoice version, applicable policy, delegation record, user identity, approval event, amount basis, and any superseding action. That gives a finance owner enough evidence to decide whether the approval stands, needs ratification, must be repeated, or should be escalated, while keeping outsourced AP support inside an evidence-preparation role.
Evidence and scope
The population includes invoice approvals performed by delegates during or near a declared delegation window, plus approvals affected by later invoice changes. Each record retains entity, invoice key and version, supplier, amount and currency, tax and freight components, converted threshold amount if policy uses one, approval step, required role, delegator, delegate, delegation identifier, scope, start and end times with timezone, creation and revocation events, authentication identity, action timestamp, system outcome, later edits, payment status, and owner disposition. The register includes rejected, returned, reassigned, auto-approved, and superseded events rather than selecting only successful approvals. Delegations for another entity, cost center, category, or amount remain visible as scope conflicts. Access to personnel and identity records stays controlled; the working packet uses only the minimum fields needed to test the event.
Key Stats
Policy reconstruction identifies the version effective when the action occurred. The preparer records whether thresholds apply to invoice subtotal, tax-inclusive total, cumulative commitment, purchase-order value, payment amount, or another approved basis. Currency conversion uses the policy's source and effective time, not today's rate. Scope is tested across entity, department, account, project, supplier class, and exception type only where the policy actually defines those dimensions. The existence of a delegation does not establish that it covered every approval held by the delegator. Conversely, an expired delegation does not by itself decide the fate of an invoice; the company may have a documented fallback or ratification process. The evidence packet states the rule and conflict without writing a new rule to resolve an awkward case.
Research-to-practice
Time reconstruction distinguishes when the delegate clicked or submitted, when the workflow accepted the event, when an asynchronous rule evaluated it, and when the status became visible. It also records delegation creation, approval, activation, modification, revocation, scheduled expiry, and any system synchronization. If systems use different timezones, UTC and original display values are retained. A click before expiry with processing afterward is not silently treated the same as a click after expiry; the policy and system owner must define which event governs. A delegation revoked while an invoice was open creates another bounded question. Later ratification is appended with its own authority and time rather than backdating the original event. This approach preserves what happened instead of editing history until the workflow appears internally consistent.
Implementation
Invoice version matters because authority can change with amount and scope. The packet hashes or otherwise identifies the document and structured record seen at approval, then compares later corrections, tax changes, currency updates, coding changes, added lines, credits, and purchase-order links. A delegate authorized below a threshold may have acted on an earlier value before a corrected invoice exceeded it. A small value reduction after approval may still require reapproval if policy says any material source change resets the chain. Support records the difference and current workflow behavior; it does not decide materiality or whether the old approval transfers. Approval comments are evidence of what the actor stated, not a substitute for the controlled source version. A current “approved” badge cannot prove which amount or attachment the user reviewed.
Key Takeaways
Challenge cases include an approval seconds before scheduled expiry; a late system timestamp after a timely user action; revocation during an open task; an invoice corrected above the delegate's limit; foreign-currency conversion crossing a threshold; a delegation restricted to one cost center; overlapping delegates; an auto-escalation that failed; and ratification after payment preparation began. A second reviewer receives frozen sources and reconstructs policy version, scope, invoice version, event times, and unresolved decision. Agreement is expected on those facts and calculations. The method fails if current roles replace historical access evidence, if timezone conversion is undocumented, if only the final invoice is retained, if ratification overwrites the original approval, or if the analyst assumes a system status is equivalent to authorized business consent.
Findings
An outsourced AP specialist may gather approved policy and workflow records, normalize timestamps, compare invoice versions and thresholds, maintain the exception queue, and request a decision from the designated owner. The specialist must not create or extend delegations, assign approver roles, change historical events, determine policy validity, ratify an approval, approve the invoice, override workflow, or release payment. Management owns authority design; system administrators own controlled configuration; finance owners decide invoice and exception outcomes. NIST access-control and audit-record concepts support least privilege, unique identity, and attributable event content. GAO's Green Book supports documented responsibility, appropriate control activities, quality information, and monitoring. These sources are control frameworks, not the company's approval matrix and not a legal opinion about agency or contractual authority.
Findings
Queue labels should describe evidence: policy version missing, delegation record missing, scope conflict, event-time conflict, threshold calculation needed, invoice version changed, identity attribution unresolved, ratification decision pending, reapproval required by owner, or disposition retained. Metrics include scoped approval events, complete delegation records, timestamp conflicts, invoice-version changes, threshold crossings, scope exceptions, later ratifications, repeated workflow defects, and second-review reproducibility. Counting “invalid approvals” would overstate what an evidence study can prove. Limitations include overwritten workflow histories, shared or migrated identities, unclear policy language, clock drift, asynchronous processing, and decisions made outside controlled systems. The defensible conclusion is narrower: an approval becomes reviewable when another person can identify the exact invoice version, authority source, delegation scope, amount basis, action and processing times, subsequent changes, and accountable disposition without relying on oral explanation or a current status badge.
Findings
The final owner packet should not bury the decision beneath workflow exports. A summary states the approval event, delegation window and scope, policy threshold calculation, invoice version reviewed, later changes, and exact conflict. It then asks one bounded question: retain, repeat, ratify, reject, or escalate under the company's defined options. The response is linked to the responsible identity and timestamp. If reapproval occurs, the new event supplements rather than replaces the disputed one. If no action is needed, the reason is retained so a later reviewer can distinguish an evaluated exception from an unnoticed defect. Aggregated findings can reveal timezone configuration, role provisioning, or workflow synchronization problems, but management owns those remedies. Support supplies the reproducible evidence and keeps the queue current; it does not convert recurring practice into unofficial policy. The packet also identifies any downstream proposal or payment state reached before the authority question was resolved. That fact changes urgency and escalation ownership, but it does not give the preparer permission to reverse, release, or otherwise alter the transaction.
Reconstruct approval authority without deciding validity
Support can align policy, delegation, invoice, and workflow events. Authorized company owners decide whether approval was valid, must be repeated, or requires escalation.
Review accounts payable servicesSources
These primary sources support the control principles and evidence boundaries in this report.
FAQs
Are the planning numbers benchmarks?
No. They describe a testable workflow shape and are not promises, market averages, or production targets.
What should an outsourced AP assistant own?
Repeatable preparation, documentation, status tracking, and follow-up within least-privilege access. Named finance owners retain approval and payment decisions.
When should an item be escalated?
When evidence is missing, a request changes payment details, a duplicate or fraud signal appears, or the item falls outside the written rule.