Skip to main content
A settlement — a billing — is the periodic account between a creditor and the collector. It says how the money collected on the creditor’s cases was split, and what the creditor is charged for the work. It ends either in a payout to the creditor or in an amount the creditor owes. Posting one correctly means fetching both halves. The payments and their distribution are one endpoint; the fees and disbursements are another. Take only the first and the account is half posted.

​
The flow

1

billings.create fires

The webhook carries a billingId, the creditorId and the currency.
2

Fetch the deposit distribution

GET /v1/{tenantId}/billings/{billingId}/deposit-distribution — every payment in the settlement and how it was split.
3

Fetch the billing vouchers

GET /v1/{tenantId}/billings/{billingId}/billing-vouchers — the fees (honorarer) and disbursements (udlæg).
4

Post it

Revenue, commission, fees, disbursements, overpayments and the net amount.

​
1. The webhook

Verify the X-Verification-Token header, acknowledge with 200, and do the fetching asynchronously. billingId is what both endpoints below take. Key the handler on it so a redelivery does not post the settlement twice. payouts.create follows when the money actually moves, with type telling you whether it is a CREDITOR_RECEIVABLES settlement, an OVERPAYMENT refund to the debtor, or a COURT_FEE.

​
2. The deposit distribution

One entry per payment in the settlement: which case and customer it belongs to, which case vouchers it was distributed across, how much of it was an overpayment, and which of the distributed amounts carry collection commission.
  • customer.referenceId and caseVouchers[].referenceId are the creditor’s own identifiers — the customer number and the invoice number that were sent in. They are what makes the settlement postable in the creditor’s system.
  • depositCaseVoucher.amount is the payment; the amounts in caseVouchers plus overpayment add up to it.
  • overpayment is owed back to the debtor, not to the creditor.

​
source says who imposed what

  • CREDITOR — imposed by the creditor: the invoices, reminder and compensation fees sent at handover, and the payments the creditor registered itself. These already exist in the creditor’s own bookkeeping.
  • COLLECTOR — imposed by the collector during collection: collection fees, court fees, interest.
The two do not line up. A CREDITOR entry can be settled by a payment the collector received, and a COLLECTOR entry by a payment the creditor received itself. depositCaseVoucher.source says who received the money; caseVouchers[].source says who imposed what it paid. Read them separately — treating one as a proxy for the other is the usual way a settlement fails to reconcile.

​
Direct payments

Payments registered with source: "CREDITOR" are not in the distribution by default, and the commission charged on them is reported as a separate fee among the billing vouchers instead. Add ?includeDepositsWithSourceCreditor=true to have them reported here with their commission as part of the distribution.
billing-vouchers always reports that commission, whatever is passed here. So when both halves of the settlement are taken — which is what this guide recommends — leave the parameter off. Turning it on and also reading the billing vouchers counts the commission on direct payments twice.

API reference: Get deposit distribution

See GET Get deposit distribution for full details.

​
3. The billing vouchers

The fees and disbursements on the settlement. Only the ones that stand on their own are returned. A fee charged on a specific deposit belongs to that deposit’s distribution and is reported there as collectionCommission, so booking both endpoints counts nothing twice — and misses nothing.
  • category is fee — the collector’s own charge, a honorar — or disbursement, an outlay paid on the creditor’s behalf, an udlæg. They usually go to different accounts, and can be fetched separately with ?category=["fee"] or ?category=["disbursement"] (JSON encoded, as on Debbie’s other list filters). Both are returned when it is omitted.
  • amount excludes VAT, and vat carries the VAT charged on the entry.
  • caseId and caseSequentialId tie the charge to a case where there is one; a charge that is not case specific has them null.
  • depositCaseVoucher is the payment that triggered the charge, where there is one. Commission on a payment made directly to the creditor appears here, with depositCaseVoucher.source set to CREDITOR.
Do not derive the fees from the case-vouchers.* webhook stream instead. A voucher event carries no billing reference, so nothing in it says which settlement a fee ends up on — or whether it has been settled at all — and a voucher can still be changed or removed after it was reported.

API reference: Get billing vouchers

See GET Get billing vouchers for full details.

​
4. Posting it

What is left is the net, which payouts.create reports when it moves.
Reconcile the parts against the settlement total before posting. If they do not add up, something was missed — most often the billing vouchers, or the direct payments landing on whichever side of includeDepositsWithSourceCreditor you did not expect.

​
Paging and scopes

Both endpoints return items plus meta, 25 per page by default, with no total count — page with page and pageSize until a page returns fewer items than pageSize. See Pagination. Both require read:billings.