Bring payments, settlement and your own data together in one place. So you can reconcile quickly and accurately.
Booking date | Reference | Gross amount | Adjustments | Fees | Net amount | Net vs. gross % |
|---|
Settlement does not sit in a separate system next to transactions. You work in the same backoffice whether you are following a payment, a refund or the payout it ends up in.
You see the same numbers across operations and finance. When a line needs to be explained, you do not have to find data in one system and keep looking in another.
You get from question to answer faster. That matters most when a payout needs to be reviewed in detail or when a discrepancy needs to be found while the case is still fresh.
| Booking date | Reference | Gross amount |
|---|---|---|
07/04/20263 days ago | P001CM594753020326 | 124.049,60DKK |
03/04/20267 days ago | P001CM649434020326 | 8.902,00EUR |
29/03/202612 days ago | P001CM611793020326 | 50.091,75DKK |
23/03/202618 days ago | P001CM482106020326 | 972,67EUR |
17/03/202624 days ago | P001CM725118020326 | 26.774,55DKK |
Each settlement is broken down into the movements that affect the payout - payments, refunds, fees, chargebacks and adjustments.
You do not just see a net amount and a date. You see exactly what builds the amount up and what pulls it down.
You can reconcile directly and explain the numbers without guessing what sits behind the total.
Settlement and transactions are linked in backoffice. When a payout needs to be checked, you can move straight to the underlying payments and refunds without starting over.
You can quickly show why an amount looks the way it does. That is especially useful when finance, support or an auditor needs an answer right away.
You avoid pulling exports from several places and matching lines by hand before you can move the case forward.
| Booking date | Transaction | Gross amount | Fees | Net amount | Fee percent |
|---|---|---|---|---|---|
07/04/2026For 6 dage siden | -259,00 DKK | -0,31 DKK | -259,31 DKK | -0,12% | |
06/04/2026For 7 dage siden | -240,00 DKK | -0,29 DKK | -240,29 DKK | -0,12% | |
05/04/2026For 8 dage siden | -50,00 DKK | -0,06 DKK | -50,06 DKK | -0,12% | |
04/04/2026For 9 dage siden | 574,00 DKK | -3,44 DKK | 570,56 DKK | -0,60% |
The difference is your own references. You can send your own fields with the transaction, such as invoice number, order ID or debtor number.
Those references are carried into settlement through the transactions, even when they are not included in the data coming from the acquirer.
So you do not only see the processor's or acquirer's references. You see the numbers the business actually works with in ERP, accounting or customer records.
| Reference | Invoice | Order | Debtor |
|---|---|---|---|
| INV-20481 | ORD-93841 | DEB-1842 | |
| - | ORD-93855 | DEB-1848 | |
| - | ORD-93857 | DEB-1850 |
Today, accounting teams typically receive settlements by email, which makes posting and reconciliation unnecessarily manual and time-consuming.
With ePay, settlement data can be automated instead.
You can fetch the data through our API, and we send a webhook notification when new data is ready to be collected.
If you do not want to fetch it through the API, the same data is also available as a CSV file directly in backoffice.