How to Automate Revolut Business Workflows with Make.com

Start with the payment process, not the connector

Before creating a Make.com scenario, define the business process that the scenario is expected to support. A payment automation may begin with an approved invoice, a supplier request, a contractor record or a refund decision. Each starting point has different data requirements and approval logic.

Write down the meaningful states in the process. For example, a request may move from Draft to Ready for review, then to Approved, Submitted, Completed or Exception. These are business states, not merely steps performed by a scenario.

Make.com is most useful when the decision logic is already understandable. If nobody can explain why a payment is eligible, who approves it or what happens when it fails, adding more modules will create a faster version of an unclear process.

Define the data and ownership model

Payment workflows become fragile when essential fields are optional, names are inconsistent or ownership is implied. Establish a minimum payment record before building the scenario.

• Request identity: a unique request or invoice ID that remains available throughout the workflow.
• Payment details: beneficiary, account information, amount, currency and payment reference, subject to the requirements of the selected payment method.
• Business context: supplier, cost centre, project, department or other information needed for review and reporting.
• Approval information: approver, decision, decision time and any relevant comment.
• Execution information: payment reference, transaction identifier, current status and timestamps returned by the payment system.
• Exception information: the reason a request stopped, the person responsible and the next action.

Also assign ownership explicitly. Finance may own payment policy, a budget owner may approve spend, an operations owner may maintain the Make.com scenario and a requester may correct missing information. These roles can belong to the same person in a small team, but they should still be named.

Connect Revolut Business to Make.com carefully

Once the process and data model are clear, create the relevant connection in Make.com and verify what the current Revolut Business integration supports. Available triggers, actions, authentication methods and permission requirements can change, so do not design a production workflow around an assumed module.

1. Create a new scenario in Make.com and add the relevant Revolut Business module or another system that will initiate the process.
2. Create a dedicated connection using an account and permissions appropriate for the workflow.
3. Confirm that the connection can retrieve or submit only the information needed for the scenario.
4. Test with non-production or low-risk records where possible.
5. Document the connection owner, purpose, date of creation and process that depends on it.

Separate development and production scenarios where the operating environment allows it. A scenario that is easy to edit but difficult to distinguish from the live payment process is a control problem, especially when financial actions are involved.

Use a simple decision sequence for payment automation

A practical design sequence is more valuable than a long list of app modules. The following model can be applied to invoice payments, supplier requests and similar workflows.

This sequence separates eligibility from execution. It also makes it easier to pause a request before money moves. A Make.com filter should enforce a documented rule, not act as a hidden substitute for finance policy.

Example: approved invoice to payment status

Consider a hypothetical business that records supplier invoices in an accounting or procurement system. The desired workflow is not simply “new invoice creates payment.” That would risk paying invoices that are incomplete, duplicated or not approved.

1. The source system creates or updates an invoice record with a unique invoice ID.
2. Make.com checks whether the invoice is in a defined state such as Ready for payment.
3. The scenario validates the beneficiary, amount, currency, reference and approval information.
4. A duplicate check confirms that the invoice ID has not already produced a payment request.
5. If the invoice is eligible, the scenario creates or prepares the relevant Revolut Business payment action supported by the current connection.
6. The scenario stores the returned reference and changes the invoice status to Submitted or another agreed state.
7. A later event, scheduled check or reconciliation step updates the record when the payment result is known.

If validation fails, the request should move to Exception with a reason and an owner. It should not repeatedly retry the same incomplete record.

Design approval workflows around decisions

Approval automation should make the decision visible rather than hide it inside email threads or disconnected chat messages. Define which conditions require approval and what evidence must be recorded.

For example, a lower-risk recurring supplier payment may follow an established route, while a new beneficiary, unusual currency or payment above a defined internal threshold may require additional review. The threshold and routing rules should come from the organisation’s policy. Make.com should implement those rules consistently.

Do not treat a notification as an approval record. A message saying “approved” may be difficult to reconcile unless it is linked to the original request and stored in a consistent field or record.

Build for duplicates, failures and manual review

Financial automations need an explicit exception path. Common failure conditions include missing beneficiary information, an unavailable connection, an invalid amount, a rejected payment request, a timeout or a scenario that runs twice for the same source event.

Use a combination of validation, duplicate protection and error handling. A useful pattern is to check whether the source record already contains a payment reference before attempting another payment action. For operations where duplicate risk is material, review the available platform controls and design an additional reconciliation check rather than relying only on timing.

Automatic retries are not always safer. A temporary technical error may be suitable for retry, while an invalid beneficiary or duplicate request requires review. The retry rule should be based on the failure type.

Monitor the workflow as an operating process

Scenario history alone is not a complete finance control. Monitor business outcomes as well as technical execution. Useful measures include the number of requests awaiting approval, requests in exception, payments without a linked source record and records that remain in a processing state longer than expected.

Reporting should support a decision. If the purpose is to reduce payment delays, report on ageing and ownership. If the purpose is to improve reconciliation, report on missing identifiers and unmatched records. A dashboard full of run counts may show activity without showing whether the process is working.

Review the workflow after changes to approval rules, account structure, source fields or payment processes. Keep a short change record so operators know what changed and when.

Apply security and change controls

Payment scenarios should have restricted editing access and a named owner. Use the minimum practical permissions for each connection and avoid placing sensitive credentials in ordinary text fields, notes or notifications.

Test mapping and routing with safe records before enabling live actions. Make a clear distinction between a scenario that prepares a payment and one that can initiate a payment. That distinction helps reviewers understand the consequence of each change.

For broader systems work, the payment workflow may also need to connect with a CRM, procurement process, reporting layer or operational workspace. The design should preserve one source of truth for each type of data instead of copying every field everywhere. ConsultEvo’s systems, automation and AI implementation services cover this kind of process and integration design. Where a CRM owns the request or supplier relationship, CRM architecture and automation support can help keep ownership and status logic consistent.

When Make.com is the right fit

Make.com can be a practical orchestration layer when the process is repeatable, the systems have suitable integrations and exceptions can be routed to people. It is less suitable as a workaround for unclear finance policy, inconsistent source data or an approval process that changes informally every week.

Start with one bounded workflow, such as approved supplier invoices, and establish the states, fields, owners and exception rules before expanding to other payment types. Once the process is stable, additional automations can be evaluated against the same operating model. More scenarios and more connected tools do not automatically create a better finance system.

A useful final test is simple: can a finance operator explain why a payment was created, who approved it, what happened afterwards and what to do if something went wrong? If the answer is no, improve the process design before adding more automation.