Test the mobile approval journey before buying finance software

A mobile approval feature is useful only when the approver can understand the decision on the available screen. Before asking a vendor to demonstrate it, identify the tasks your managers would reasonably complete away from a desk. A routine expense with a clear receipt may fit. An unusual supplier change or a complex allocation may need more review.

Write down what approval means in the proposed workflow. It may confirm a business purpose, authorize an invoice for posting, or release a later payment step. Those are different decisions. The mobile label should not make a manager believe that reviewing an expense has also authorized money to leave the bank.

Choose a small set of representative examples and use test records. Tell the vendor that the session must show the complete journey from notification to the finance team's resulting record. A screenshot of an approve button is not enough to assess that journey.

Use a phone similar to the ones your team is expected to use. Ask an ordinary approver, rather than the sales presenter, to open the request. Check whether the supplier, amount, currency, business purpose and due date are visible without navigating through several unrelated screens.

Open the attachment. Can the approver enlarge a receipt, return to the request and retain their place? Try a multipage invoice, a photograph taken in poor light and a document with a long description. These examples help reveal whether the mobile workflow supports inspection or merely displays a summary.

Include one discrepancy that should stop approval. A request might show a different currency from the attachment or lack an explanation for an extra charge. The approver should have a clear way to ask a question and send the item back without accidentally accepting it.

Ask what changes when the approver taps each action. An approval should identify the item and amount to which it applies. If several items can be approved together, check whether the screen makes the selection obvious and allows the user to inspect exceptions before confirming.

Look closely at adjacent controls. W3C's minimum target-size guidance addresses the size or spacing of pointer controls and includes exceptions. Use it as a reference for the interface review, while also watching whether your approver can operate the actual screen reliably with one hand.

Test a wrong selection using harmless records. Can the user cancel before final submission? If the action is already complete, is the correction route clear and does it retain a history? A small button can be troublesome, but an unclear final action can cause confusion even when every control is large.

Real approvals happen between other activities. During the demonstration, switch to another app, allow the screen to lock, or move away from the request before completing it. Return and check whether the displayed details still match the record. Ask what happens if the underlying invoice changes during that pause.

Use a vendor-approved way to simulate an interrupted connection. After submitting a test approval, examine the result in both the mobile app and the finance system. If the phone shows an uncertain status, the user should be able to determine whether the action succeeded before trying again.

Do not assume that a spinner means the action failed or that a success banner means every later step completed. Ask the vendor to distinguish submission, acceptance and downstream processing. The user-facing message should support that distinction without requiring managers to understand technical logs.

Send a test item back with a specific question. Have the preparer answer and resubmit it. Observe whether the approver can see the earlier question, the reply and any changed amount. The useful test is whether the second review is informed by the first, rather than starting from an unexplained new notification.

Try a request that changes from $480 to $680 in a hypothetical example. Confirm what happens to the earlier approval and which person must review the additional $200. The exact routing depends on your policy and the product's configuration, so require the vendor to show the behavior you intend to buy.

Check reassignment during leave. A substitute approver should receive the relevant evidence and the appropriate authority. Avoid treating a forwarded notification as a complete delegation process. Ask where the reassignment is recorded and how the original manager sees the final outcome.

After the mobile action, ask the finance user to open the item on a desktop. Look for the approver, decision time, approved version, comments and remaining steps. If finance must ask the manager what they meant, the mobile experience has left part of the work unfinished.

Check a rejected and a pending item as well as an approved one. The queue should help staff distinguish something waiting for evidence from something declined for a substantive reason. Otherwise the finance team may repeatedly chase a manager who already explained why the request cannot proceed.

Discuss notification choices. Too many reminders can encourage reflexive approval, while missing reminders can leave items untouched. Ask which settings the company controls and which belong to individual users. Set the demonstration to a plausible frequency rather than accepting every default.

Ask whether mobile approval requires a separate license, a particular user role, an installed app or additional identity management. Include the necessary setup and training in the comparison. A feature described as mobile access may offer a different experience in a browser than in the vendor's native app.

Record the devices, operating-system support and features actually demonstrated. Obtain the vendor's current support requirements before purchasing devices or committing to a rollout. Keep those details in the implementation record so the team does not train users on a workflow that their equipment cannot run.

Finish with a clear boundary: which requests managers can approve on a phone, which must move to a larger screen, and how uncertain submissions are checked. The resulting policy should reflect observed usability and the evidence required for the decision.