Esker mobile approvals need context-equivalence checks

Define the decision context before enabling mobile action

The direct answer is to identify the evidence an authorized person must see before a mobile action can have the same meaning as the governed desktop decision. Esker's official source-to-pay page describes mobile-friendly reviewing and approving across key workflows. That establishes provider positioning for access and action. It does not establish that a customer's mobile presentation includes every fact, attachment, warning, exception, and authority check material to a particular approval.

For a purchase request, the decision context may include requester, business purpose, supplier identity and status, item or service detail, quantity, total and currency, tax, freight, budget and commitment impact, contract and catalog status, competitive process, conflicts, policy exceptions, delivery location, data or security review, attachments, prior approvals, and change history. Define required context by decision type and risk rather than assuming a compact screen can omit fields available elsewhere.

Prove that the mobile and primary views are equivalent

Equivalence does not require identical layout, but it requires identical decision meaning. Test field values, totals, currencies, line-level exceptions, attachments, linked contract clauses, approval history, warnings, and allowed actions against the authoritative record. Long supplier names, many lines, nested tax, translated text, and large attachments should not be truncated into a misleading summary. A link back to the full record is useful only if the approver can open it before acting.

Record the application and interface version, device and session, record version, data refresh time, notification time, view time, fields and attachments available, warnings presented, authentication or reauthentication, action, reason or comment, timestamp, and authoritative write receipt. If the transaction changes between notification and action, stop or require review of the new version. A mobile success message is not enough when the source system rejected the decision.

Preserve delegation, abstention, and exception paths

Mobile convenience should not broaden authority. Evaluate role, legal entity, business unit, category, amount, currency conversion, cumulative threshold, segregation of duties, conflict, leave coverage, and delegation effective dates at action time. Show the approver why the item reached them and what authority they exercise. Forwarding a notification or sharing a device must not transfer approval rights, and biometric or device access alone does not establish procurement authority.

Allow request-more-information, abstain, reject, reassign under policy, and open-exception actions alongside approval. If connectivity is poor, distinguish a locally queued intention from a decision committed to the authoritative workflow; do not promise offline approval unless conflict and version behavior are defined. High-risk or materially changed transactions may require step-up authentication or a richer review surface. Retain every failed, withdrawn, superseded, and overridden action.

Test a changed request on a constrained screen

A useful evaluation sends a multi-line purchase request with a contract exception, foreign currency, attachment, sensitive supplier change, and near-threshold cumulative spend to a mobile approver. Change the total after notification, let the session age, interrupt connectivity during action, and exercise a temporary delegation. Reviewers should see the material context, block stale or unauthorized action, preserve the queued attempt, and reconcile the final decision to the source-system version and audit trail.

Esker's public page supports the attributed description of its connected source-to-pay, guided purchasing, approvals, policy, exception, human-validation, and mobile-access positioning. It does not establish a customer's context design, screen equivalence, data freshness, attachment rendering, permission model, delegation, authentication, offline behavior, authoritative write, audit evidence, policy compliance, implementation effort, or outcome. Procurement, finance, accounts payable, information-technology, security, accessibility, compliance, audit, and legal owners retain those judgments.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Procurement Technology Current will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.