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.
This guide covers billing settlements between creditor and collector. Register case voucher allocation records a creditor payment or credit note against one or more case vouchers. Its response lists the created vouchers, one per case, rather than a billing to post.

​
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 and credit notes 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.

​
Registering payments and credit notes

Register payments received directly by the creditor and credit notes through Register case voucher allocation. Both create one voucher with source CREDITOR per matched case and apply its amount to the specified case vouchers through fixed distributions on that case. Set voucherTypeId to select the entry: Supply a matches array. Each match contains a positive amount in minor units and exactly one of caseVoucherId or caseVoucherReferenceId, looked up within creditorId. The identifiers can be mixed in the same request. Partial amounts are supported, up to each target’s remaining fixed-distribution capacity. Each target may appear only once, and all targets must use the same currency. Debbie groups the matches by case, sums their amounts, and creates one payment or credit note per case. Its fixed distributions only point to vouchers on that same case. The response is an array containing each new caseVoucherId, its voucherTypeId, and its targetCaseVouchers with the matchedAmount for each target. Send one Idempotency-Key for the entire request. All matches are registered in one transaction: if any match fails, no payment or credit note is created. A credit note reduces the invoice balance without recording cash received. It already exists in the creditor’s own books; do not post its amount again as a payment or as money paid out by the collector. The billing endpoints describe the resulting billing and its charges, rather than a complete list of the credit notes registered by the creditor. Registering either type requires write:case-vouchers.

​
Direct payments in the billing

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 billing endpoints require read:billings.