Jurisdiction Pricing Carveouts

How bilateral pricing agreements affect case creation and contract signing for specific debtor jurisdictions.

What Is a Jurisdiction Pricing Carveout?

A jurisdiction pricing carveout is a bilateral pricing agreement between Debitura and a referral partner that overrides the standard SDCA pricing for a specific combination of referral partner + debtor country + collection partner.

Carveouts are per-debtor-jurisdiction, not partner-wide. Whether a carveout applies depends on the country of the specific debtor in the case — not on the referral partner's country or account-level settings.

Business context: See Referral program overview for details on how referral pricing is structured.

Amount Thresholds

A carveout defines a set of pricing tiers covering specific claim amount brackets. Claims that fall below the lowest bracket are not covered by the carveout and fall through to standard SDCA pricing instead.

This means:

• The JPA signing requirement does not apply to sub-threshold claims
• Sub-threshold cases can be submitted without a signed JPA, even when a carveout is active for that jurisdiction
• The exact threshold is specific to your carveout configuration — confirm the value with Debitura

Signing Scenarios

When a case is created, Debitura evaluates whether a carveout applies to the debtor's country and amount. This determines what signing, if any, is required before the case can proceed.

Scenario	What the API requires
No carveout for debtor country	Standard SDCA + PoA flow (no carveout involvement)
Carveout exists, claim amount below threshold	Standard SDCA flow — no JPA required
Carveout exists, JPA not signed	Same 422 as missing PoA — solutionUrl points to PoA signing page
Carveout exists, JPA already signed	Case proceeds normally

Internally, the PoA signing flow handles three combinations:

PoA needed	JPA needed	What happens
true	true	PoA and JPA documents are merged — one signature covers both
true	false	PoA document only
false	true	JPA document is presented as PoA
false	false	All signing complete — no action needed

From the API's perspective, the distinction between PoA and JPA is never surfaced. The signing URL always points to the same PoA signing flow, regardless of which documents are bundled inside.

How the API Communicates Carveout Requirements

Error on Case Creation

When a case requires a JPA that has not been signed, the API returns 422 Unprocessable Entity with a MissingPowerOfAttorney business error — the same error returned for a missing PoA. The solutionUrl always points to the PoA signing page.

{
  "businessErrors": [
    {
      "type": "MissingPowerOfAttorney",
      "message": "Power of attorney not signed with partner X.",
      "solutionUrl": "https://referral.debitura.com/PowerOfAttorney/Sign/..."
    }
  ]
}

MissingJurisdictionPricingAppendix is never returned by the API. All missing-signing requirements, including carveouts, surface as MissingPowerOfAttorney. See Error Handling for how to handle 422 responses.

Checking Contract Status

Use GET /cases/{id}/contract-status to determine what signing is outstanding for a case in PendingContractSigning state.

GET https://customer-api.debitura.com/cases/{caseId}/contract-status
Authorization: Bearer {clientToken}

The response includes a needsPoaSigning field that consolidates both PoA and JPA requirements.

Which field carries the signing URL depends on what is missing:

Situation	poa.solutionUrl	pricingAppendix
PoA missing (no carveout)	Set	null
JPA missing, PoA already signed	null	Set with solutionUrl
Both missing	Set	Set with solutionUrl

Example — JPA missing, PoA already signed:

{
  "sdca": {
    "signed": true,
    "requiresResigning": false
  },
  "poa": {
    "signed": true,
    "requiresResigning": false,
    "solutionUrl": null
  },
  "pricingAppendix": {
    "signed": false,
    "requiresResigning": false,
    "solutionUrl": "https://referral.debitura.com/PowerOfAttorney/Sign/..."
  },
  "collectionPartnerName": "Oriel Collections Limited",
  "needsPoaSigning": true
}

needsPoaSigning is true when:

• The PoA is missing or stale, or
• A jurisdiction pricing appendix is required for the debtor's country and has not been signed

needsPoaSigning is false when all required signing is complete.

Recommended implementation: When needsPoaSigning is true, use poa.solutionUrl if non-null, otherwise fall back to pricingAppendix.solutionUrl. The signing flow is context-aware — it detects whether a JPA is required for the debtor's country and bundles it into the same session. See White-Label UI for how to handle the redirect.

Onboarding vs Post-Onboarding

The carveout signing experience differs between the initial onboarding flow and case creation.

During Onboarding

The onboarding SignAgreements step can present up to three checkboxes:

• SDCA
• SDCA + PoA
• SDCA + PoA + carveout

When a carveout applies, the third checkbox is shown with the carveout's configured label text (for example, "UK Pricing Appendix"). A single signature covers all checked agreements.

After onboarding, no further carveout-specific UI is shown. The referral partner integration does not need to differentiate between PoA and JPA in the post-onboarding flow. See Client Onboarding for how SDCA and PoA signing are handled during onboarding.

After Onboarding — First Case in a Carveout Jurisdiction

When a creditor submits their first case in the carveout jurisdiction (whether they onboarded before or after the carveout was configured), the flow is:

1. Case submission — POST /cases returns 422 MissingPowerOfAttorney with a solutionUrl
2. Present signing URL — redirect or surface the solutionUrl to the creditor
3. Creditor signs — the JPA is presented on the Debitura-hosted signing page
4. Redirect back — creditor is redirected to your returnUrl after signing
5. Retry submission — resubmit the same case; it now proceeds without error

This is identical to the missing-PoA flow. No carveout-specific handling is required in your integration.

Creditors onboarded before the carveout was activated

If a carveout is added to your Debitura account after creditors are already active, those creditors will receive a 422 MissingPowerOfAttorney on their next case submission in the carveout jurisdiction — even though they have already signed their PoA. This is expected: the JPA is a separate agreement requiring its own signature.

To avoid all existing creditors hitting a hard 422 simultaneously on go-live, consider using allowPendingContracts: true during your rollout window. Cases will be created in PendingContractSigning state instead of being rejected outright, giving creditors time to sign the JPA before their cases are actioned. Once rollout is complete, you can remove the flag.

After Onboarding (Ongoing)

Once a creditor has signed the JPA, carveout requirements are absorbed transparently into the standard PoA flow:

• The API only returns MissingPowerOfAttorney — never MissingJurisdictionPricingAppendix
• The solutionUrl always points to the PoA signing page
• Your integration does not need separate logic for carveout jurisdictions

Contract Validation

Customer API calls always use strict contract validation — a 422 is returned when contracts are unsigned. To opt in to permissive mode (case created as PendingContractSigning instead of failing), set allowPendingContracts: true in the case creation request body.

Integration Checklist

Before going live with a carveout jurisdiction, verify:

• 422 handling is in place — your integration catches MissingPowerOfAttorney and surfaces the solutionUrl to the creditor
• Return URL is configured — your returnUrl in the signing flow brings the creditor back to a sensible location after signing
• Retry logic is implemented — after the creditor signs and is redirected back, the case submission is retried
• Sub-threshold cases work — claims below the carveout threshold submit successfully without a signed JPA
• Test environment validated — run the full flow in the test environment: submit a case in the carveout jurisdiction → get the 422 → sign the JPA → retry → confirm the case is created
• Rollout strategy decided — if existing creditors are already active, decide whether to use allowPendingContracts: true during the rollout window to avoid a hard cutover