Orders vs payments
This page explains what orders are and how they are different from payments
This page explains how Orders work and has the following sections:
Orders vs payments
On the Accounts page we saw that payments are linked to Orders. In this page we will explain what Orders are.
Expenses, supplier payments, subscriptions and disbursements are all Orders in Yordex. Orders can have more than one payment. For example, subscriptions or orders with partial payments have more than one payment.
In addition to payment details, orders also contain other information. For example they contain a link to the supplier (trader), approvals, receipts, categorisations and, if provided, line item details
The table below summarises the difference between Orders and payments in Yordex.
| Orders | payments | |
|---|---|---|
| APIs | POST /orders GET /orders PUT /orders/:id | GET /reports/yordexpay |
| Represents | Expenses, subscriptions, supplier payments, disbursements and any other payment type you need | Card payment, bank transfer or card top up |
| Contains | Payments, supplier, approvals, payment terms, invoices/receipts, line item details, categorisation and different statuses | Payment details |
As you can see from the table, it is not possible to create a payment directly. All payments are either created by cards or orders. To pay out to someone you can either
- Give them a card and top up the card
- Create an order linked to a card and the order will top up the card
- Create an order that will trigger a bank transfer (same tutorial)
Order lifecycle business perspective
Yordex differentiates between payouts and expenses. All of them are orders in our system but in our app we usually call it spend collectively.
| Process | Payment Types | |
|---|---|---|
| Payouts | Created and approved before they are paid | Card payouts or bank transfer payouts (ACH, SEPA, Faster Payments etc) |
| Expenses | Paid first and then possibly approved (approval is optional for expenses) | Paid on card |
As you will see below, technically both payouts and expenses are the same in our system. The only difference is their lifecycle.
Payouts lifecycle:
- Order created
- Order approved: equivalent to a PO approval
- Order confirmed: equivalent to confirming receipt of goods or services
- Payment made
- Order completed
A few things to know about the Payouts process:
- The invoice can be added to the order at any time, but usually it is done before the order is confirmed. It is possible to not complete the order until the invoice has been provided. In that case it will in a WAITING_FOR_INVOICE status until the invoice has been provided
- Payments are only made on the payment due date. The payment due date is normally taken from the invoice or set by the user If neither was provided, it defaults to the date the order was confirmed plus the payment terms, e.g. plus 30 days
- Payouts can be recurring, e.g. for online subscriptions. In this case the 'order confirmed' and 'payment made' steps are repeated until the subscription runs out
- Payouts can be partially paid. In this case the 'order confirmed' and 'payment made' steps are repeated for the remainder of the payment
Expenses lifecycle:
- Card holder makes a payment on card
- (Optional) card holder provides receipt and line manager approves
- Order completed
A few additional things to know about all spend (both payouts and expenses):
- Who needs to approve orders and confirm receipt of goods and services is configurable. Please contact us to set these up
- Payouts can have cost allocations which usually mirror what you have in your accounting system. These can be set up in the Settings section of our app
Order lifecycle API perspective
An Order has one or multiple Events. Every event represents a payment. The difference between an Event and a payment are:
- Events are created before the payment is made allowing the payment to be pre-approved
- Invoices or receipts are linked to Events, not to payments
Event approval is separate from Order approval. Typically an Order approval indicates that the purchase can be made while the Event approval indicates that the goods or services were delivered so the payment can be made.
Orders and Events therefore each have their own statuses that are separate but linked:
- An Order is only COMPLETED when all Events are COMPLETED
- Only one Event can be 'active' at a time: an event will remain NOT_STARTED until the event before it is COMPLETED
- The Order has to be APPROVED before the first event becomes active. It is however possible to amend an order (temporarily move it back to NOT_APPROVED for editing) when Events are still active
An order lifecycle can be summarised like this:
To illustrate this process, here is a workflow an Order with two Events could go through:
At the start, the statuses will be as follows:
- Order: NOT_APPROVED
- Event 1: NOT_STARTED
- Event 2: NOT_STARTED
Once the order is approved and the first event is for confirmation, the statuses will be as follows:
- Order: APPROVED
- Event 1: FOR_CONFIRMATION
- Event 2: NOT_STARTED
Once the first event is completed and the second event is for confirmation, the statuses will be as follows:
- Order: APPROVED
- Event 1: COMPLETED
- Event 2: FOR_CONFIRMATION
If you amend an order that was already in progress, the statuses will be as follows:
- Order: NOT_APPROVED
- Event 1: COMPLETED
- Event 2: FOR_CONFIRMATION
The order state goes back to NOT_APPROVED and the order has to be approved again, but the event states do not change throughout this process.
Once all events are completed, the statuses will be as follows:
- Order: COMPLETED
- Event 1: COMPLETED
- Event 2: COMPLETED
Updated 5 months ago