Skip to main content
A settlement — a billing in the API — is the periodic account between you and your debt collection partner. It says how the money collected on your cases was split, and what you are charged for the work. It ends either in a payout to you or in an amount you owe. Posting one correctly means fetching both halves of it. The payments and how they were split 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

Debbie calls your webhook endpoint with a billingId.
2

Fetch the deposit distribution

GET /billings/{billingId}/deposit-distribution — every payment in the settlement, and how each was split between you and your collection partner.
3

Fetch the billing vouchers

GET /billings/{billingId}/billing-vouchers — the fees (honorarer) and disbursements (udlæg) you are charged.
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. A webhook of yours only ever carries your own creditor’s events. See Webhooks for delivery and retry behaviour, and Create webhook to subscribe. If you would rather not run a webhook receiver at all, the settlement is also in the creditor portal, and the billingId is all these endpoints need.

2. The deposit distribution

One entry per payment in the settlement. Each says which case and customer the payment belongs to, which entries it was distributed across, how much of it was an overpayment, and which of the distributed amounts your collection partner charges commission on.

Reading it

  • customer.referenceId is your customer number and caseVouchers[].referenceId is your invoice number — the values you sent in. This is what makes the settlement postable: each amount lands on the invoice it paid.
  • depositCaseVoucher.amount is the payment. caseVouchers is what it was distributed to, and those amounts plus overpayment add up to it.
  • overpayment is the part that exceeded the debt. It is owed back to the debtor, not to you, and needs its own account.

source is what tells you what is already in your books

Every entry carries source:
  • CREDITOR — you imposed it. The invoice, the reminder fee, the compensation fee you sent at handover, and the direct payments you registered yourself. You already have these postings, so a distribution to them is money against a receivable you already carry.
  • COLLECTOR — your debt collection partner imposed it. Collection fees, court fees, interest calculated during collection. These do not exist in your system until this settlement puts them there.
Do not assume the two sides line up. A CREDITOR entry can be settled by a payment the collector received, and a COLLECTOR entry can be settled by a payment you received yourself — the source of the payment and the source of what it paid are independent. Read depositCaseVoucher.source for who received the money and caseVouchers[].source for who imposed what it paid, and post them separately. Treating one as a proxy for the other is the usual way a settlement fails to reconcile.

Direct payments

By default the payments you registered yourself are not in the distribution, and the commission charged on them shows up 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.
The billing vouchers endpoint always reports that commission, whatever you pass here. So if you take both halves of the settlement — which is what this guide recommends — leave the parameter off. Turning it on and also reading the billing vouchers counts the commission on your direct payments twice.

Paging

The response is items plus meta, 25 payments per page by default. Page with page and pageSize until a page returns fewer items than pageSize; there is no total count. See Pagination.

API reference: Get deposit distribution

See GET Get deposit distribution for full details.

3. The billing vouchers

The other half: the fees and disbursements on the settlement. Only the ones that stand on their own are returned. A fee charged on a specific payment belongs to that payment’s distribution and is reported there as collectionCommission, so booking both endpoints counts nothing twice — and misses nothing.
  • category is either fee — your collection partner’s own charge, a honorar — or disbursement, an outlay they paid on your behalf, an udlæg. They are usually posted 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.
  • label is what the line is called, in the language of the settlement.
  • 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 direct payment you registered yourself appears here, with depositCaseVoucher.source set to CREDITOR — that is where it goes when you did not pass includeDepositsWithSourceCreditor=true on the distribution.
  • The response is paged the same way as the distribution.

API reference: Get billing vouchers

See GET Get billing vouchers for full details.

4. Posting it

Once you have both halves, a settlement decomposes into: What is left is the net: paid out to you when the settlement is in your favour, invoiced to you when it is not.
Reconcile the settlement against its total before posting it. If the parts do not add up to the amount your debt collection partner paid out, something was missed — most often the billing vouchers, or the direct payments landing on whichever side of includeDepositsWithSourceCreditor you did not expect.

Scopes

Both endpoints require read:billings on the API key. A key only ever reaches its own creditor’s settlements.