Consolidate Claims Use Case

When a credit agreement is accelerated — for example after several missed instalments, the whole remaining balance becomes due — the individual instalment claims are typically replaced by a single claim for the enforceable balance. Consolidation is a two-step, client-side operation, and the platform keeps the lineage queryable through typed claim relations (relatedClaims).

Example:

Let's assume John Doe has two overdue instalment claims (claim-inst-3, claim-inst-4, 150 euros each) and you accelerate the agreement, making 600 euros enforceable.

Step 1 — close the instalment claims (they are superseded, not paid):

POST /v1/3d132b18-6b6f-4f7c-b464-6a8ee7ca5235/resolve_claims HTTP/1.1
Host: api.receive-demo.com
Content-Type: application/json
Authorization: {{access_token}}

[
  { "ref": "claim-inst-3", "reason": "CLAIM_INVALIDATED" },
  { "ref": "claim-inst-4", "reason": "CLAIM_INVALIDATED" }
]

Step 2 — place the consolidated claim, declaring what it replaces:

POST /v1/3d132b18-6b6f-4f7c-b464-6a8ee7ca5235/create_claims HTTP/1.1
Host: api.receive-demo.com
Content-Type: application/json
Authorization: {{access_token}}

{
  "claim-accelerated": {
    "amount": 60000,
    "currency": "EUR",
    "currentDueDate": "2026-08-01",
    "originalDueDate": "2026-08-01",
    "accountReference": "JOHN_DOE_ACCOUNT",
    "relatedClaims": [
      { "type": "REPLACES", "claimReference": "claim-inst-3" },
      { "type": "REPLACES", "claimReference": "claim-inst-4" }
    ],
    "primaryDebtor": {
      "lastName": "Doe",
      "firstName": "John",
      "debtorReference": "JOHN_DOE_ID",
      "contactInformation": {
        "country": "DE",
        "email": "john.doe@acme.com"
      }
    }
  }
}

The consolidated claim gets a full collection journey, and get_account_claims returns the relations so your reporting can always trace which claims it replaced.

Notes:

The consolidated amount must be the legally enforceable balance at consolidation time — never more than what the debtor actually owes (for interest-bearing credit, rebate unearned future interest).
relatedClaims is lineage metadata: the platform stores and returns it but does not act on it — resolving the replaced claims (Step 1) is your responsibility.
Relation types besides REPLACES cover other flows: SPLIT_FROM (a claim split out of another, e.g. the disputed part of an invoice), REINSTATES (re-placing debt whose claim was already resolved, e.g. a broken settlement), REFINANCES (a new agreement that cures old debt), RESTRUCTURES (the same debt re-scheduled by agreement), and DEFERS (a fee claim gating a due-date deferral). See the field documentation in the API reference.
Do not use linkGroupId for consolidation — linked claims are synchronized mirrors of the same debt for shared-liability scenarios, and linking independent claims makes their amounts overwrite each other.

FAQ

How can I get an Access Token? You can get a token using the Authentication Use Case
Why resolve the old claims with CLAIM_INVALIDATED and not CLAIM_PAID? The instalments were not paid — they were superseded. Using the right reason keeps your recovery reporting honest.
Can the debtor still pay in instalments after consolidation? Yes — offer an instalment plan on the consolidated claim (via strategy or the landing page). That is the platform's collections treatment for repayment schedules.

FAQ

Related Pages