Managing approvals becomes challenging as businesses grow. Manual processes cause delays, and separate tools for different expense types add complexity.

The Approval Rules Builder simplifies this challenge by automating approvals for cards, employee expenses, and accounts payable. With customizable rules based on amount, team, user, supplier, department, cost centre, general ledger codes, or any combination of these (and more), you have full control over who approves what and when.

It’s flexible enough to handle routine approvals, high-value transactions, and unique exceptions—ensuring requests are routed efficiently and compliance is maintained. Built-in tracking and audit trails provide complete visibility at every step.

Here are some examples to help inspire you to build an approvals structure in Moss that will work for your business.

All travel and incidental expenses need to be approved by the spender’s manager. First, manually allocate every user a manager or do this automatically by connecting with your hr software. And then create a rule like this:

The HR team needs to approve all employees’ learning & development, work from home and other stipend expenses:

Software subscription requests and bills need to be approved by the specific person in charge of technical operations:

Before an invoice can be paid by finance, the recipient of the delivered goods or service must confirm they received matches what they ordered and what has been billed, as well as confirming the cost centre from which it should be deducted. Then the cost centre manager must confirm they have accounted for it in their budget.

First enable the Verify step, then select the recipient of the goods/service the invoice, each supplier can be given a default verifier to automate the selection. Then set up the approval step with the following rule:

The marketing department has 3 teams (Content & brand, Social & influencers, Paid ads). Each team uses their own budget and team members use cards to spend freely their budget. The team managers and the department manager can spend within their budget without any approval needed:

We run multiple projects at a time, and each project has its own budget. Each project team is cross functional, with members from different departments in the business. Project expenses need to be approved by the project manager, and not the project member’s departmental line manager.

We track our projects in accounting software. Alter the name of cost centre or cost carrier to Project in “Settings” > “Accounting” > “Dimensions” > “Edit Dimension”. Assign each ‘project’ a manager in accounting settings. Ensure the ‘project’ field is made visible on card requests and purchase requests using the mandatory fields capability It is editable by default on invoices, card transactions and reimbursements.

Your approval rule book consists of multiple rules that seamlessly work together to form a comprehensive framework, determining who should automatically receive an approval request in various scenarios.

Each individual rule consists of:

Each organisation can have multiple rules. Each organisation/entity has its own set of rules. If your organisation has multiple entities, rules must be created and maintained independently; they cannot be duplicated across different entities.

Rules have a priority order. Rules are evaluated from top to bottom in the order you set them. The first matching rule is used and any rules below that will not be considered. Therefore it’s important that you place your most broad and generic rules lower in the list then your more specific ones. As such, your entire list of rules need to be created and reviewed together to ensure that the automation of approval requests works as you desire.

Read mode. When you first land on the Approval Rules screen you’ll see a read-only list of the rules you currently have published. This is the set of rules (and the order) that is currently being used to automate approval request routing in your organisation. To make any changes click “edit” to enter “edit mode”.

Edit mode. In edit mode you can: create a new rule (including by duplicating an existing rule), delete a rule, edit a rule, change the sort order of your rules. Once you’ve made changes you have 3 options. Publish, this will set live your changes and use the newly updated rules to automate routing of approval requests in your organisation. Save for Later, this will save a draft of your list of rules for you to revisit in case you need to review and complete your rules at a later time (for example, after consultation with your colleagues) - when you hit save for later, the previously published list of rules remain in use and the draft list will be shown when you next enter ‘edit mode’. Cancel, if you made changes but don’t want these changes to update your current draft list.

If you’re doing a lot of work on your rules in one session and you don’t want to lose the changes, remember to hit ‘save for later’ occasionally.

Approval requests are automatically triggered based on specific actions users take in the Moss platform. We call these Request types. Below is a detailed overview of each request type, its purpose, and how it interacts with approval workflows:

Approval requests for card requests are generated when:

Customers can decide when approval requests for reimbursements should be initiated, based on their preferences:

Approval requests for invoices are triggered once they have passed the Review step in the invoice workflow.

If the Verify step is enabled, the approval request will be initiated only after the invoice has been verified.

Approval requests for purchase requests are triggered automatically when a purchase request form is submitted. This ensures that purchase decisions are reviewed and approved before proceeding.

Approval requests for card transactions are triggered after the cardholder has attached a receipt to the transaction and filled in any mandatory fields (if these have been configured). This ensures all necessary details are provided before approval is initiated.

Approval rules can be applied to one or several request types simultaneously. If a rule is applied to a request type that is not included in your current plan, it has no negative impact. For instance, if a rule is set to apply to Card Requests, Invoices, Purchase Requests, and Card Transactions, but your plan only includes Cards, the rule will be applied exclusively to Card Requests.

For Card Requests, Purchase Requests, and Card Transactions, a ‘Review’ step before approval is currently not supported. This means for ‘field based rules’ the finance team cannot review and input accounting details before these are sent for approval. These approval requests will be triggered based on the field values entered by the requester or cardholder.

Purchase Requests and Invoices are currently treated as a combined category, and independent rules for these request types cannot be created at this time.

Conditions in approval rules define when a rule should be triggered, providing flexibility and granularity to your approval workflows. Below is a comprehensive guide on each condition type and how they function within the system.

Conditions can be set as “is not” or “is”. For example, use this rule of expense account IS learning development or use this rule if expense account IS NOT learning development. Use IS NOT when (a) the rule should apply in the majority of cases and (b) you want to ensure approval requests do not slip through the cracks due to forgetting to select one of several options.

Field-based conditions are determined by the values in specific accounting fields when a request or expense is submitted for approval.

Accounts Payable Customers. Most Accounts Payable customers will want field-based approvals due to the volume of supplier bills processed. Routing based solely on the submitter’s role or amount is often inadequate. Field-based rules make it possible to route approvals effectively using supplier names, cost centres, or specific expense accounts.

Cards and Employee Reimbursement Customers. Customers managing complex budgets or multi-department spending will benefit from field-based rules. These are ideal for:

Cost Centre. The condition is based on the cost centre linked to the request or transaction. Since the name of this field can be customised in your accounting settings, it may appear differently depending on your configuration.

Cost Carrier, Similar to cost centres, cost carriers represent an additional accounting dimension used to categorise expenses. The field name can be modified in accounting settings to suit your organisational structure.

[Custom Dimension]. For customers using more than two accounting dimensions in addition to Cost Centre and Cost Carrier, Custom Dimensions provide flexibility for specialised tracking. If you have created additional accounting dimensions you will see them as conditions to select from.

Expense Account. This condition is tied to the expense accounts in your chart of accounts (GL/nominal codes), allowing you to route approvals based on the predefined accounting categories used to classify transactions.

Supplier. The Supplier condition is triggered based on the supplier associated with the request.

Submitter-based conditions are used to determine approval workflows based on the individual or entity initiating the request. You can learn more about teams, department’s, submitter’s managers and in this article about how set up approval and oversight of employee expenses.

For invoices, where suppliers can directly submit documents, consider using the manually entered fields (such as Team or Verifier) during the review step to set the correct context.

Departments are a higher-level grouping than Teams. This condition applies to the Department that the Submitter’s Team is mapped to, or to the Department that the Team selected manually for an invoice or purchase request is part of.

Teams are organisational units to which users are assigned in Moss. This condition is determined based on the Submitter’s Team or the Team manually assigned to an invoice or purchase request during the review process.

User refers to the individual submitting the request or expense. It allows for approval rules to be based on specific users, enabling you to handle exceptions for users that fall outside of the typical organisational structure.

Amount-based conditions allow for more detailed approval flows based on the value of the request. While it’s common to use thresholds for approval steps, you can also define separate approval paths for different amount ranges using Amount as a Condition. See examples of when to use amount as a condition vs as a step threshold in the section below.

Card Type condition (coming soon) will allow for rules to differentiate based on the type of card requested or used for a transaction. This would be particularly useful for distinguishing between subscriptions and regular card spend.

The Approvers section of approval rules defines who needs to review and approve a request before it’s finalised. Setting up approvers correctly is crucial for ensuring compliance, maintaining proper oversight, and enforcing separation of duties.

Approval workflows can include one or more steps, and each step can have different approvers and amount thresholds. Below, we’ll explain the details of configuring approvers, using conditional steps, and enforcing the 4-Eyes Principle to ensure effective approval processes.

Approvers can be grouped into multiple steps within a rule. Each step must be approved sequentially—meaning Step 2 will only be initiated if Step 1 has been fully approved, and so on. This allows for multi-layered approval workflows that can incorporate a variety of rules and checks.

Conditional Approval Steps

Approval steps can also be configured so that they are only triggered if the total amount of the request or expense exceeds a certain value. This setup is particularly useful for multi-level workflows that require an extra approval for higher amounts.

For example, you can have:

In this example, for a €200 expense first Bob will be asked to approve, once Bob has approved the request, step 2 is triggered which requires Sally to now approve the request. Once Sally approves the request it is follow approved and Step 3 is ignored as the request is not greater than or equal to €500.

If, however, you would like, for example:

Then you would create separate 3 rules that use Amount as a condition:

Rule 1: Condition if Amount is €0-99 then, Approvers = Step 1: Bob. step amount is greater or equal to 0. Step 2: Charlie. step amount is greater or equal to 49

Rule 2: Condition if Amount is €100-499, then Approvers = Step 1:Sally. step amount is greater or equal to 100. Step 2: Tony. step amount is greater or equal to 249

Rule 3: Condition if Amount is €500+, then Approvers = Step 1:Mark. step amount is greater or equal to 500. Step 2: Nigel. step amount is greater or equal to 1000

Approval rules allow you to assign different types of approvers, each serving specific roles in the workflow. The available approver types include:

Named Individuals:

Specific people identified by name (e.g., Jane Doe or John Smith). Use this when there are particular individuals who should be involved in a specific approval step.

Anyone within a specific Team

Approval can be routed to anyone from a specific team. 1 of the team members must approve.

Role-Based Approvers:

Approvers can be assigned based on their role within the organisation, including:

Smart Roles:

Smart roles are dynamic roles that adjust based on the context of the request or the organisation’s structure. These will be explained in detail in a separate section. When configuring rules, refer to the Smart Roles section of this article for more information on how these roles function and are automatically determined.

Each rule has its own setting for how to handle cases where the same person is asked to approve twice or the approver is also the submitter.

With these settings you allow or prevent a single person from having authority over the approval of a request or expense. This is best explained with examples.

Let’s say 1 needs 2 out of 3 people to approve certain expenses. I would configure my approvers as such:

Step 1: Ricardo, Martina or Nikita can approve

Step 2: Ricardo, Martina or Nikita can approve

Or if Ricardo, Martina and Nikita are in the same team and I always need 2 approvals from anyone in this team (regardless of who the members of the team are at the time of the request) then I would configure my approves like this:

Step 1: Team HR can approve

Step 2: Team HR can approve

However, if, for example, Ricardo approved in Step 1 then we don’t want to allow him to approve in Step 2, we must get the next approval from Martina or Nikita. To set this up you need to select the Require Someone Else’s Approval option for the “If the approver already approved” scenario in the 4 eyes section of your Rule. With this set the 4 eyes principle will be enforced automatically for you.

Example: Bob must approve all card requests.

When the person who submits a request is also listed as an approver, it can create conflicts of interest. To prevent the submitter from approving their own request you need to select the Require Someone Else’s Approval option for the “If the approver is also the submitter” scenario in the 4 eyes section of your Rule.

Step 1: submitters manager

Step 2: cost centre manager

Step 3: any admin

Step 4: Bob

Step 5: Jane

In this example, it’s possible that the same person could be the approver for every step.

Harry submits a card request for the Project 1 cost centre.

Bob is Harry’s manager, he is also the cost centre manager for Project 1, he is also an admin, he is Bob, and Jane is absent and Bob is her substitute approver.

To ensure a different person approves in each step you would need to have selected the “someone else must approve” option. This would prevent Bob from covering all 5 steps.

Instead Bob would approve in step1. Bob’s manager will approve in Step 2. Any admin will be asked to approve in step 3. A different admin will be asked to approve in step 4. And Jane will be required to approve in step 5.

Alternatively, in these scenarios, you may want to either automate the approval from the person in question or still require them to manually approve. You can control this independently for each rule, giving you full flexibility. You can also apply this setting to all rules in bulk and adjust the default setting for new rules you create.

Whilst in read mode, you can filter your list of rules by Request type to get a clearer overview of which rules will be considered for each spend workflow (AP, cards, reimbursements, card transactions). Filtering is not available in edit mode.

To find rules that include a particular condition or approver we recommend using command/ctrl F.

Field-based approvals are not available on all plans. This means that certain advanced features, such as specific conditions or smart roles, might not be accessible to all customers. If a rule relies on a condition or smart role not included in the customer’s plan, the rule can still be created, but it will be excluded when evaluating which rule to apply for any given request or expense.

What Happens to Excluded Rules?

Field-based approval rules allow approval workflows to change dynamically based on specific accounting attributes. There are two main types:

Field-Based Conditions. These conditions let the entire approval workflow change depending on the details of the request or expense at submission. Common field-based condition types include:

Field-Based Smart Roles. Smart roles adapt the approver selection within an approval step based on the request’s financial context. For example, the right manager is chosen based on the cost center linked to the request. Field-based smart roles include:

When an invoice or expense is split into multiple line items with different accounting fields, the approval system processes the entire transaction as a single entity. This section explains how the system evaluates approval rules in these cases and highlights key behaviours and limitations.

Rules Apply to the Entire Invoice but considers specific line-item details for triggering.

Main Invoice Amount Used for Approval Decisions:

Rule Order Determines Priority:

Smart Roles for Cost Centre Managers:

Scenario 1: Rule Prioritisation

Scenario 2: Using Smart Roles for Cost Centre Managers

Summary: