Moss’s approval capabilities automate approval routing across all of your spend - corporate cards, employee reimbursements, and accounts payable. With customisable 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. Additionally, built-in tracking and audit trails provide complete visibility at every step.
Approvals in Moss are flexible enough to handle routine approvals, high-value transactions, and unique exceptions—ensuring requests are routed efficiently and compliance is maintained. See here for examples of just some commonly used approval rules.
Take a look at this demo of the new approval rules:
Approval rule book
What is the approval rule book?
Your approval rules consist of multiple rules that seamlessly work together to form a comprehensive framework like an approval rule book. This rule book determines who should automatically receive the approval request for any scenario.
Each organisation/entity has 1 rule book with its own set of rules. If your organisation has multiple entities, rules must be created and maintained independently for each; they cannot be duplicated across different entities.
How does the rule book prioritise?
Rules are evaluated from top to bottom in the order you set them. The first matching rule that can be applied will be used and any rules below won’t be considered. Therefore it’s important that you place the more specific rules first in the list, and the broad / generic rules lower in the list. As such, your entire list of rules need to be created and reviewed in one to ensure that the automation of approval requests works as you desire.
Draft mode: Each organisation/entity has a draft rule book. This allows you to work on your rule book over time, consult with colleagues and iterate on it before finalising it for use throughout the organisation.
Anatomy of an approval rule
Each individual rule consists of
01: Rule name
Each rule should have a unique name.
02: Request types
Rules can apply to certain types of requests. You can decide how many and which request type the rule should apply to. We have 4 different types of requests:
Invoices & Purchase Requests
Reimbursements
Card requests
Card transactions
With the 4 request types, you can create general organisation-wide rules that will apply to everybody. These are often used as the general rules that will be used if there are no more granular rules. More granular rules can be created with conditions.
Request type | Approval requests sent when... |
Card requests |
|
Reimbursements |
|
Invoices & purchase requests |
|
Card transactions |
|
Known Limitations
Purchase requests will use the same approval rules as for invoices. Hence, they are grouped together as one request type. Rules that apply to invoices and purchase requests will be considered when either a purchase request or an invoice is submitted for approval.
03: Conditions
Conditions allow you to make rules more granular and/or handle exceptions to general rules, e.g. you can have an organisation-wide general rule for invoices but maintain a different rule for the marketing department.
Below you can see the conditions that can be used to set up rules.
Condition | Approval requests sent if... | Important to note |
User | ...the submitter is [this user] or [this user]... | User is not recommended to be used for invoice rules as the submitter is often the supplier and not a Moss user. |
Team | ...the submitter is in [this team] or [this team]... | The team of a request or expense is determined by the submitter's allocation to a team. The exception is invoices and purchase requests where a team field can be used, however it's preferable to use accounting field conditions in this case. |
Department | … the submitter’s team is in [this department] | Users and not assigned directly to teams. Department contain teams and teams contain users. There is no department field on expenses or requests. |
Cost Centre, Cost Carrier, Expense Account, Supplier, Custom Dimension | ... the request or expense is attributed to [this cost centre] | Recommended for invoices as the pre-accounting is typically done before approval. And this is a more efficient method than using Teams and Departments. |
Amount | ... the total amount is greater than or equal to [this amount] and below [this amount]. | The total amount is used (line item amounts are ignored). The currency used it the entity's default currency. |
Card type | ... the type of card requested or used is subscription or virtual or physical or single purchase or project. | Only relevant to Card Request and Card Transactions. |
04: Approvers and thresholds
There are various ways to select who should approve each rule, here is the breakdown:
Approver | Require approval from... | Important to note |
Users | ... a specific user | Any invited user can be selected. |
... any admin (or accountant) | All users with the selected role at time of submission will be asked to approve, but approval is only needed from one of them. | |
... all members of the selected Team | All members of the selected team at the time of submission will be asked to approve but approval is only needed from one of them. Team Managers are excluded unless they are also included as a Team Member. | |
Submitter's Manager or Submitter's Manager's Manager | ... the manager of the user who submitted the request or expense | This is not recommended for use with Invoices where the submitter is typically an external supplier. Note that each user in your organisation should have a manager assigned. |
... the team manager of the user who submitted the request or expense | Each user should be put in a team and each team should be given a manager. | |
Department Manager | ... the manager of the department that the submitter's team belongs to | Note that users are not mapped directly to departments - departments are made up of Teams. |
... the manager of the cost centre the expense or request is to be attributed to | Each cost centre needs to have a manager assigned. | |
... the manager of the cost carrier the expense or request is to be attributed to | Each cost carrier needs to have a manager assigned. |
Approval steps
If multiple approvals are required you’ll need to create multiple approval steps. Here’s how it works.
How approval steps work
Each rule must have at least 1 approval step.
Each approval step can contain multiple approvers.
Only 1 of the approver listed in each step is required to approve.
Multiple steps should be added to require multiple approvals.
There is no limit to the number of steps that can be added per rule.
Approvers in step 2 are only notified after step 1 is complete and so on.
Approval steps can be made conditional based on the transaction being greater than or equal to a certain amount.
In this case the total amount is recognised (line item amounts are ignored).
The currency used it the entity's default currency.
Thresholds:
Threshold amounts can be assigned to each step - when it is so, the respective step will be required if the amount exceeds the defined threshold.
05: 4-Eyes settings
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.
Example: I need approval from 2 of a specific group of people.
Let’s say that you require 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.
Field based rules
Rules can also be based on the value present in specific accounting fields at the time a request or expense is sent for approval. This can be done via 'field based conditions' or 'field based approver roles'.
Field based: conditions
Field based conditions allow an entire approval workflow to differ depending on the accounting fields allocated to the request or expense at the time of submission for approval:
Supplier
Expense Account
Cost centre
Cost carrier
Field based: approver roles
Allow the specific approver within a specific step to be different depending on the cost centre or cost carrier the request or expense has been allocated to. The available “field based” approver roles are:
Cost centre manager
Cost carrier manager
When should you use field based approval rules?
Accounts payable:
If you have suppliers sending invoices directly to a centralised accounts payable email inbox you will need field based approval routing rules.
Field-based approval rules work especially well for invoices because (a) the submitter is not a user and (b) the accounting fields of invoices are pre-populated and entered by the finance team during the review step of the workflow before invoices are sent for approval.
Cards and reimbursements:
If travel and incidental expenses need to be approved by the functional line manager of the employee, whereas all personal development or software costs need to be approved centrally by the HR team or the head of IT.
If the spender is irrelevant and the primary way of routing approvals is based on the nature of the spend. For example, a consultant can work on multiple projects and incur expenses that need to be paid from the relevant project’s budget.
Examples of common approval use cases
Take a look at some common use cases. Those might give you a general idea on how you want to setup your rules before we explain how to structure your approval rules in details.
🧾 Accounts payable release workflow
🧾 Accounts payable release workflow
Before an invoice can be paid by finance, the recipient of the delivered goods or service must confirm that what they received matches what they ordered and matches 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 or services being billed on the invoice., each supplier can be given a default verifier to automate the selection. Then set up the approval step with the following rule:
👩💻 Marketing spend
👩💻 Marketing spend
Imagine the marketing department has three teams (Content & Brand, Social & Influencers, Paid ads). Each team uses their own budget and team members use cards to freely spend their budget. In this scenario, the team managers and the department manager can spend within their budget without any approval needed: