A trade claim in xMatix is an amount a partner is owed — or owes — that is raised as a document, reviewed line by line and then settled by another document. Scheme payouts, price support, damaged or short deliveries, transport reimbursement and service reimbursements are all claims; what differs is the claim type, which decides how lines are populated and which settlement setup applies. Claims can be typed in by hand or produced in bulk by a claim generation setup that sweeps a source entity on a schedule.
Where claims live
Claims have their own Claims app: Claim Overview Dashboard, Claims, Claim Batches, Claim Reconciliations, Claim Generation Setups, Claim Settlement Setups, Reports, Dashboards and Settings. The Sales app does not host claims. Claims is also its own product licence; the Claim, Claim Line, Claim Batch, Claim Reconciliation, Claim Generation Setup and Claim Settlement Setup entities are only reachable when the licence is assigned to the organization and to the user's security profile, and the user's profile must additionally grant entity permissions on Claim and Claim Line. Claims that come out of a generation setup are ordinary Claim records, so the same screens and permissions apply.
Find a claim
- 1
The view heading and its menu switch between saved views of the Claim entity (All Claims and any organization-defined filters); New creates a manual claim.
- 2
Summary cards count claims by status and type for the current view - a quick read of how much is still in Draft versus approved.
- 3
Search by claim number; the filter and column controls narrow the list by partner, branch, claim type or status.
- 4
Name is the claim number; open it to reach the Claim Lines, Details and Approval tabs.
- 5
Claim Type (Service, Sale, Purchase, Transport, Shortage, Damaged, Excess...) and Status (Draft, Approved, Claim Approved...) - the status wording depends on the approval process configured for claims.
- 6
Total Amount is the claimed total; the approved figures that actually settle live on the claim lines.
The All Claims view lists Name, Partner Account, Branch, Claim Type, Status and Total Amount, with summary cards above the register; other saved views (for example a per-claim-type filter) are selected from the view menu next to the heading. Search by claim number, then filter by partner, branch, claim type and status so review starts from the intended population. Open a record from its name.
Read a claim
- 1
The status tag shows the claim's picklist status (here Claim Approved). Only an approval-process decision, not this tag, queues settlement.
- 2
Approve All, Perform Populate Lines and Perform Reconciliation are the Claim actions; Reject All sits under the arrow. Approve All / Reject All only act when the matching Approve All or Reject All flag is set on the claim.
- 3
The stepper is a fixed Draft, Pending Approval, Approved, Rejected, Settled illustration; the real status is the picklist value in the header tag and on Details.
- 4
Claim Lines, Claim Checklist, Related, Details and Approval are the tabs described on this page.
- 5
Claim Type, Claim Quantity and Claim Amount per line are the claimed values; approved and rejected quantities live on the line record and drive settlement.
- 6
The Checklist panel is a manual reviewer aid: its Pass/Fail choices are not stored on the claim and prove nothing about approval or settlement.
The record header shows the claim number, its status tag, Partner Account, Branch and Claim Type, and the actions Approve All, Perform Populate Lines, Perform Reconciliation and, under the arrow, Reject All. The stepper underneath (Draft, Pending Approval, Approved, Rejected, Settled) is a fixed illustration of the lifecycle; the authoritative value is the status tag, whose picklist is described below.
Claim Lines is the approval basis. Each line carries an item or description, its own line claim type (Part To Part, Reimbursment, Shortage or Damaged), the claimed quantity and amount, a unit price, and the approved and rejected quantities that approval writes. Lines have a row action Open Checklist and can be added with New.
The Claim Checklist tab and the Checklist panel beside the lines are manual review aids built into the standard layout. Their Pass/Fail and Yes/No choices are not bound to any field, so nothing is saved: they help a reviewer work through a warranty-style check, but they are not evidence that a review, approval or settlement happened. Organizations can replace the layout with their own checklist.
Related lists documents linked to the claim — delivery orders, invoices and adjustments — and is populated only after a settlement or reconciliation has created one of them; on an unsettled claim every list is empty.
- 1
Details tab: the header fields of the claim, grouped in collapsible sections.
- 2
Partner Account and Branch are the partner and branch the claim is raised for; generated claims fill them from the partner and branch paths of their setup.
- 3
Supplier Account is the party the claim is claimed from; batching skips claims that have no supplier.
- 4
Status is the picklist value (Draft, Pending Approval, Claim Approved, Claim Rejected, Reconcile); settlement writes Settled here.
- 5
Claim Type selects the active Claim Settlement Setup and, on manual claims, what Perform Populate Lines reads.
- 6
Related Source links a manually created claim to its origin document: bill return, sale invoice, goods receipt, service contract or service order. Perform Populate Lines reads from these links.
Details has two sections. Key Information holds Partner Account, Branch, Supplier Account (the party the claim is claimed from), Status, Claim Type and Name. Related Source holds the optional back-links of a manually created claim — Bill Return, Sale Invoice, Goods Receipt, Service Contract and Service Order — which Perform Populate Lines reads. The Approval tab shows the approval process history once the claim has been submitted.
Actions on a claim
| Action | What it does |
|---|---|
| Perform Populate Lines | Builds claim lines from the linked source by claim type: Service reads the linked service order; Purchase, Damaged, Shortage and Excess read the credit-note lines of the linked bill return. Sale is a stub that creates nothing, and Scheme, Transport and Part To Part have no populate path — lines for those types are generated or entered by hand. |
| Approve All / Reject All | Copies the claimed quantity into the approved quantity (and zeroes the rejected quantity) or the reverse, on every line. Both buttons run the same routine, which is driven by the Approve All and Reject All flags on the claim rather than by which button was pressed: with neither flag set the buttons change nothing, and if both are set the approve path wins. They write quantities only, never the line status or the claim status. |
| Perform Reconciliation | The legacy adjustment-plus-invoice path described in the Reconciliation section below. |
| Edit, Delete | Standard record maintenance; a claim in a batch or already settled should not be deleted. |
Status and approval
The Claim Status picklist ships with Draft (default), Pending Approval, Claim Approved, Claim Rejected and Reconcile. Two more values are written by code rather than chosen: generation creates claims as Draft, and every settlement path sets Settled.
Approval is an approval process on the Claim entity. No first-party approval process is shipped for claims, so the organization configures one (Setup → Automation → Approval Processes): its submission rule moves the claim to Pending Approval, and its final-approval field updates decide which status text is written on approval and rejection. Settlement listens to the approval decision, not to the status text: a decision of Approved on a Claim queues the per-claim settlement job for that claim; a rejection queues nothing. Claim types whose settlement setup is Per Batch are left for the batching sweep instead.
Approval is partial by design. Approvers set the approved quantity per line (or use Approve All and then correct individual lines); whatever is approved settles, and the rejected remainder never becomes a payout.
Config-driven generation
- 1
The All Claim Generation Setups view in the Claims app; New creates a setup.
- 2
Document Number and Claim Type identify the setup and the coded type it stamps on generated claims.
- 3
Source Entity is what the setup sweeps; Schedule Group is the scheduled run it belongs to (blank = manual only).
- 4
Run Order sequences setups within a schedule group, ascending.
- 5
Active and Simulate Mode: read both on the exact row before running - here every setup is active and not simulated, so a run writes real claims.
A claim generation setup names a source entity and describes the whole pipeline declaratively — no code per claim type. The register shows each setup's claim type, source entity, schedule group, run order and its Active and Simulate Mode flags; inspect those two flags on the exact row before running anything, because a copied setup can carry a different state from the one its name suggests.
| Setup element | What it controls |
|---|---|
| Source entity + filter expression | Which records are candidates |
| Rules | Field/operator/value conditions on the Rules tab, combined with AND, OR or a custom logic formula |
| Date window | Restricts candidates by a date field (last month, this month, last N days) |
| Grouping fields | Which candidates merge into one claim |
| Aggregation | Sum an amount field (with an optional formula) into one line, or Per Record — one claim line per source row |
| Header and line mappings | Field-by-field mapping from source to claim, with tokens for constants, items, the aggregated amount and formatted text |
| Netting | Subtract a second source's total per group (for example credit notes already issued) |
| Owner resolution and supplier | Who owns the claim and who it is claimed from |
| Claim type | Fixed on the setup, or read from a source field |
Each run streams the source in batches, groups and aggregates, then builds a generation key ClaimType|GroupKey|Period, where the period is the month the run executes in. A claim with the same key is skipped on a rerun, whether or not a processed-source flag was configured; groups whose netting leaves nothing positive produce no claim. A setup that writes to a different target entity than Claim relies on the processed flag instead of the key. The full field reference and authoring procedure are in Authoring a claim generation setup.
Scheduled runs and simulate mode
Setups belong to a schedule group (Nightly, Weekly, Monthly (Day 1)) and carry a Run Order. A scheduled run executes only the active setups of its group in ascending run order, as a background job. The Generate Claims action on a setup enqueues that one setup regardless of its Active flag and returns a job run id; results are read on the Jobs screen (Setup → Administration → Jobs), where the run summary counts claims, lines and skipped candidates per setup. A simulated run reports what it would have written — including a preview of the first groups — without creating records or flagging sources. A setup can also auto-submit its new claims to the approval process; if that fails for a claim, generation is still successful and the failure is logged.
Settlement setups
A Claim Settlement Setup tells the settlement job what approval produces for one claim type. The job picks the active setup whose Claim Type equals the claim's type exactly; without one it stops with "No settlement setup for claim type".
| Field | Meaning |
|---|---|
| Claim Type | Must match the value stamped on the claims. The setup's picklist is the generation engine's coded vocabulary and can differ from the Claim entity's own claim-type list. |
| Settlement Document | Credit Note (default), Invoice, Adjustment (Part to Part) or None |
| Header Mapping / Line Mapping | Optional JSON that shapes the resulting document; tokens @approvedAmount, @approvedQuantity and @const:<value> are available |
| Auto GL Posting | Posts the credit note or invoice after creation; for an adjustment it runs inventory posting |
| Apply To Open Invoices | Knocks a credit note off against the partner's open invoices, oldest first; ignored for other document types |
| Raise Event Name | Publishes a business-rule event after settlement, best-effort — it fires even when the document is None |
| Settlement Grouping | Per Claim (default) or Per Batch (consolidated) |
| Batch Grouping Fields, Batch Period, Batch Filter | How the batching sweep groups approved claims (see below) |
| Active, Simulate Mode | Only active setups are used; a new setup starts in simulate mode |
Saving refuses Per Batch together with Adjustment, and compiles the batch filter expression as a dry run. Keep Simulate Mode on until the approved quantities and mapped output agree with an independent calculation: in simulate mode the job reports the document it would have created and leaves the claim unsettled.
Settlement
Only an Approved approval decision queues the per-claim settlement job. The job follows the active setup for the claim type and works from the approved values only — lines with a zero approved quantity are dropped, and each remaining line is priced at unit price × approved quantity:
- Credit Note — one line per approved claim line, linked back to the claim, optionally applied to open invoices and posted.
- Invoice — bills the counterparty from the approved values and links the invoice to the claim.
- Adjustment — a part-to-part inventory adjustment from the approved quantities, the shortage-claim path.
- None — creates nothing and only raises the configured event.
Every path checks its back-link (the claim's credit note, or an adjustment or invoice already carrying the claim id) before creating another document, so a rerun does not duplicate. On success the claim's status becomes Settled. The job appears as Settle claim on the Jobs screen, runs one claim at a time per organization, retries up to three times and can be triggered manually from there.
Batches
For a setup with Per Batch grouping, the Batch claims for settlement job sweeps claims of that type that have no batch and no credit note yet and that pass the setup's Batch Filter (default Status == "Approved"). Because the shipped status picklist has no plain "Approved" value, either the approval process must write exactly that text or the filter must be changed to match the status your process writes — otherwise the sweep finds nothing. Claims are grouped by Batch Grouping Fields (default partner account, branch and supplier account), plus the calendar month when Batch Period is Month; claims with no supplier account are skipped with a message. Each group becomes a Claim Batch named CB-<group key> in Draft status. An existing Draft, unreconciled batch for the same partner, branch and supplier is reused; a monthly batch is never reused. The sweep itself never settles anything.
Settlement of a batch is started with the Settle Batch action on the Claim Batch record. It consolidates the approved claims into one credit note or one invoice (Adjustment is never batched); while any claim in the batch is still undecided the action is blocked unless it is run with the allow-partial option, which releases the undecided claims from the batch and settles the rest. Every settled claim is marked Settled.
Reconciliation
The Claim entity keeps a legacy Perform Reconciliation action. It attempts two things: an inventory adjustment from lines whose line claim type is part-to-part, and a sale invoice from Reimbursment lines with an approved quantity, then marks the claim reconciled (a flag; the status text is unchanged). The adjustment leg compares the line type against Part to Part while the shipped picklist value is Part To Part, so in practice only the invoice leg produces a document. It does not create a Claim Reconciliation record — that register in the app is a separate, manually maintained entity — and it is unrelated to the settlement job. Use it only where that adjustment-plus-invoice workflow is the organization's intended process.
Common questions
What does simulate mode actually do?
On a generation setup it runs selection, rules, grouping, aggregation and netting, then reports the candidate groups in the job summary; it creates no records and changes no processed flags. On a settlement setup it makes the settlement job report the document it would have created and leave the claim unsettled. Read the flag on the exact setup you are about to run rather than trusting a name or an old screenshot.
Can the same source records generate a claim twice?
Not within a month for a plain Claim target: the ClaimType|GroupKey|Period key blocks a second claim for the same type, group and run month, and the run counts it as skipped. A rerun in the following month produces a new period and therefore a new claim unless a processed flag was configured. A custom target entity has no key guard and depends entirely on its processed flag; see the authoring page before using that mode.
What happens when a claim is only partly approved?
It settles partially. The credit note, invoice or adjustment is built from the approved quantities, so a claim approved at 60% produces a 60% document. The rejected remainder simply never becomes a payout.
Why did an approved claim not settle?
Check, in order: the approval decision was Approved (a status edit by hand does not trigger anything); an active Claim Settlement Setup exists whose Claim Type equals the claim's type exactly; that setup is not in simulate mode; the type is not Per Batch (which waits for a batch and Settle Batch); and the Settle claim job run on the Jobs screen for the claim's error text.