Approval policies
Learn how to create and customize the approval policies for payables.
Automating accounts payable workflows with rules-based decision-making and advanced approval policies reduces manual processes, saving time and minimizing the risk of errors.
Monite allows entities to customize and automate the set of roles and approval conditions to change the payable status according to the business needs of the entity with approval policies.
Some examples of approval policies:
If the payable:
- was received from a specific counterpart (vendor or supplier),
- was uploaded by a specific entity user,
- was uploaded by any user with a specific role,
- is in a specific currency (such as EUR or USD),
- has a specific amount to be paid (for example, ≥ 5000 EUR or 100-500 USD),
- has specific tags assigned to it,
- or any combination of these conditions,
then it should be approved by:
- a specific entity user (such as the Finance Manager),
- any user with a specific role,
- any N users from the given list,
- several entity users in a specific order (for example, first by the Team Lead, then by the Finance Manager).
Entities can create multiple approval policies with different trigger conditions to cover the business needs.
With approval policies, the payable flow works as follows:
Approval policy conflicts
Avoid creating approval policies with overlapping conditions. If a payable matches the conditions of multiple approval policies, no policy will be applied to this payable.
Approval policies are defined using the MoniteScript and consist of two parts:
trigger: The conditions that define which documents this approval policy applies to. See examples.script: Specifies the logical statement to be executed. See examples.The optional priority field defines the order in which approval policies are evaluated. When multiple policies match, the one with the highest priority is applied. This prevents invoices from getting stuck when no policy matches or when several overlap. Higher numbers mean higher priority. The default is 1, with a valid range from -32,768 to 32,767. null is allowed and treated as unset.
Below is a sample approval policy that requires approval from two users of a list for any payables over 500 worth submitted for approval:
This instance of an approval policy applied to a payable is called a Process.
To create a customized approval policy, follow these steps:
To manage the approval policies, the entity users must have a specific role assigned that allows them to create, read, update, and delete the approval policies.
This role is created by calling POST /roles:
The successful response contains the ID assigned to this role:
The previously created role ID must be assigned to the entity user that will create the workflow. The entity-level token is still necessary for this action. Call PATCH /roles/{role_id}:
To create an approval policy, call POST /approval_policies passing the approval policy script:
Submit the payable. If the collected payable matches the approval policy trigger conditions, it will automatically be inserted into this approval policy.
If the approval policy started for a payable requires the approval of specific entity users, reminder notifications are sent by email indicating when the payable needs to be approved or paid.
The notification email contains information about the payable and the link to perform the required action.
The link for approval can be defined in the partner settings by calling PATCH /settings:
Once all the required approvers have approved the payable, the entity user who uploaded the invoice is notified by an email with information about the invoice to be paid and a link to the payment provider.
To get a list of all existing approval policies, call GET /approval_policies:
The successful response contains information about all approval policies:
The results can be:
Sorted by:
namecreated_atupdated_atFiltered by:
object_type: exact matchID: exact matchname: exact match, contains, icontainscreated_by: exact matchcreated_at: gt, gte, lt, lteupdated_at: exact match, gt, gte, lt, lteSome examples:
GET /approval_policies?id__in=9d2b4c8f-2087-4738-ba91-7359683c49a4&id__in=20354d7a-e4fe-47af-8ff6-187bca92f3f9 - get approval policies based on their IDs.GET /approval_policies?created_at__gte=2022-01-01T00%3A00%3A00 - get all approval policies created on or after January 1, 2022.See also the standard pagination, sorting, and filtering parameters.
To get information about a specific approval policy, call GET /approval_policies/{approval_policy_id}:
The successful response contains information about the informed approval policy:
To update an existing approval policy, call PATCH /approval_policies/{approval policy_id}.
To delete an existing approval policy, call DELETE /approval_policies/{approval policy_id}.
It is not possible to delete or modify a approval policies currently active (e.g. there are business logic objects currently being processed by the approval policy).