Approvals & Workflows

Understand how store operation requests flow through approval, including role-based access, rejection reasons, and automated fraud detection.

Every store request and payment request in Eleo flows through an approval process before it can be fulfilled or disbursed. This ensures that spending is controlled, operational needs are validated by management, and there is a clear audit trail for every decision.

Who can approve

Approval rights are role-based. By default, team members with the Manager role or above can approve and reject requests. This includes Store Managers, Area Managers, and Administrators. Staff members can create and submit requests but cannot approve their own or others’ requests.

If your organization uses custom roles, the store_operations/manage permission controls who can approve. You can assign this permission to any custom role through Team → Roles & Permissions.

Approval flow

When a request is submitted, it enters the approval queue. Here is how a manager processes it:

1. 1

   Review request details

   Open the request from the approval queue or the Store Operations dashboard. Review the request type, category, priority, and any notes from the submitter. For payment requests, check the payee details and disbursement method.

2. 2

   Check items and amounts

   Review the individual line items, quantities, and estimated costs. For payment requests, verify the requested amount against any attached invoices, quotes, or supporting documents.

3. 3

   Review fraud risk indicators

   If the request has been flagged by Eleo’s fraud detection engine, review the risk indicators. The system shows which rules were triggered and the severity level. Take these into account when making your decision.

4. 4

   Approve or reject

   Click Approve to move the request to fulfillment, or click Reject to send it back. If rejecting, you must provide a reason so the submitter understands why and can revise if appropriate.

Rejection with reasons

When a manager rejects a request, they are required to provide a reason. This serves two purposes: it helps the submitter understand what needs to change, and it creates an audit trail of decision-making. Common rejection reasons include:

• Insufficient budget for the requested amount
• Duplicate of an existing request
• Missing supporting documentation or receipts
• Incorrect payee or disbursement details
• Items can be sourced through existing supply chain

Rejected requests can be revised and resubmitted by the original creator. The full history of submissions and rejections is preserved in the request’s audit trail.

Fraud detection

Eleo includes an automated fraud detection engine that evaluates every payment request before it reaches the approver. The engine applies 14 configurable rule types designed to catch suspicious patterns:

• Individual amount limits — Flags requests that exceed a configured maximum amount for a single transaction.
• Daily cumulative limits — Flags when total requests from a single user or store exceed a daily threshold.
• New payee detection — Flags payments to payees who have never received a payment before.
• Velocity checks — Flags when multiple requests are submitted in rapid succession.
• Split payment detection — Flags when a large payment appears to have been split into multiple smaller requests to avoid approval thresholds.
• Round amount detection — Flags suspiciously round amounts that may indicate estimated rather than actual costs.
• After-hours submissions — Flags requests submitted outside of normal business hours.
• Duplicate detection — Flags requests that closely match recently submitted or approved requests.
• Self-payment detection — Flags when the submitter and the payee are the same person.
• Category mismatch — Flags when the payment amount is unusual for the selected category.
• Frequency anomaly — Flags when a user’s request frequency deviates significantly from their historical pattern.
• Budget threshold breach — Flags when a request would push the store over its operational budget.
• Unreconciled advance check — Flags when a user requests a new advance while having outstanding unreconciled advances.
• Payee concentration — Flags when a disproportionate share of payments goes to a single payee.

Risk severity levels

Each triggered fraud rule assigns a severity level that determines what happens to the request:

• Warn — The request is flagged with an informational warning but can still be approved normally. The approver sees the warning and can take it into consideration.
• Escalate — The request is escalated to a higher-level manager for review. It cannot be approved by the regular approval role and requires someone with escalation authority.
• Block — The request is auto-rejected on submission. Its rejection reason records which rule fired, and both the requester and the store owner are notified. There is no unblock or override — the request is finished.