Reconciliation breaks
- POST
/reconciliation/break/{reference}/assignAssign a break to somebody - POST
/reconciliation/break/{reference}/resolveClose a break with a reason code - GET
/reconciliation/definition/{code}/break-queuePage a definition's open break queue - GET
/reconciliation/definition/{code}/breaksRead a definition's break queue - GET
/reconciliation/run/{reference}/breaksRead the breaks a run raised - GET
/reconciliation/run/{reference}/ladder-notesRead the ladder notes a run recorded - GET
/reconciliation/run/{reference}/matchesRead the matches a run committed
POST Assign a break to somebody
POST /reconciliation/break/{reference}/assign
Assignment does not reset the age. A break handed between three people over two weeks is two weeks old, and a queue that says otherwise is measuring handovers rather than unresolved money.
Headers
| Name | Notes |
|---|---|
Authorization | Bearer token |
X-Tenant | Your tenant |
X-Environment | test or live |
Content-Type | application/json |
Path parameters
| Name |
|---|
reference |
Example
Request body: AssignBreakRequest · Response: GenericResponseBreakResponse
curl -X POST "https://api.bridgemoni.com/reconciliation/break/b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e/assign" \
-H "Authorization: Bearer $BRIDGEMONI_TOKEN" \
-H "X-Tenant: $BRIDGEMONI_TENANT" \
-H "X-Environment: $BRIDGEMONI_ENV" \
-H "Content-Type: application/json" \
-d '{
"assignee": "string"
}' {
"assignee": "string"
} {
"data": {
"reference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"runReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"definitionCode": "string",
"breakKey": "string",
"category": "string",
"sideKey": "string",
"entityCode": "string",
"entryReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"externalReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"amount": "string",
"currencyCode": "string",
"valueDate": "string",
"status": "string",
"ageingStage": "string",
"ageBusinessDays": 0,
"firstSeenAt": "string",
"firstSeenRunReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"lastSeenRunReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"seenInRuns": 0,
"assignedTo": "string",
"assignedAt": "string",
"resolutionCode": "string",
"resolutionNote": "string",
"resolvedBy": "string",
"resolvedAt": "string",
"carriedReason": "string",
"instructionReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e"
},
"description": "Break assigned successfully"
} Responses
| Status | When |
|---|---|
200 | Break assigned successfully |
POST Close a break with a reason code
POST /reconciliation/break/{reference}/resolve
The code is required and the free-text note is not, which is the right way round: a queue closed with prose and no codes cannot be counted, so nobody ever sees that a third of last quarter's differences were one counterparty making one mistake. Closing a break twice is refused - two names against one decision leaves neither accountable.
Headers
| Name | Notes |
|---|---|
Authorization | Bearer token |
X-Tenant | Your tenant |
X-Environment | test or live |
Content-Type | application/json |
Path parameters
| Name |
|---|
reference |
Example
Request body: ResolveBreakRequest · Response: GenericResponseBreakResponse
curl -X POST "https://api.bridgemoni.com/reconciliation/break/b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e/resolve" \
-H "Authorization: Bearer $BRIDGEMONI_TOKEN" \
-H "X-Tenant: $BRIDGEMONI_TENANT" \
-H "X-Environment: $BRIDGEMONI_ENV" \
-H "Content-Type: application/json" \
-d '{
"resolutionCode": "string",
"status": "string",
"note": "string"
}' {
"resolutionCode": "string",
"status": "string",
"note": "string"
} {
"data": {
"reference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"runReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"definitionCode": "string",
"breakKey": "string",
"category": "string",
"sideKey": "string",
"entityCode": "string",
"entryReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"externalReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"amount": "string",
"currencyCode": "string",
"valueDate": "string",
"status": "string",
"ageingStage": "string",
"ageBusinessDays": 0,
"firstSeenAt": "string",
"firstSeenRunReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"lastSeenRunReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"seenInRuns": 0,
"assignedTo": "string",
"assignedAt": "string",
"resolutionCode": "string",
"resolutionNote": "string",
"resolvedBy": "string",
"resolvedAt": "string",
"carriedReason": "string",
"instructionReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e"
},
"description": "Break closed successfully"
} Responses
| Status | When |
|---|---|
200 | Break closed successfully |
GET Page a definition's open break queue
GET /reconciliation/definition/{code}/break-queue
Ordered by age in business days, then by value, then by insertion - so the first page is the hundred breaks that matter rather than the hundred that happen to be oldest by row number. Paging matters here at scale: a queue of a hundred thousand open breaks returned in one response is a queue nobody can work. A size above one hundred is clamped rather than refused, because a caller asking for more should get the maximum rather than an error they have to handle.
Headers
| Name | Notes |
|---|---|
Authorization | Bearer token |
X-Tenant | Your tenant |
X-Environment | test or live |
Path parameters
| Name |
|---|
code |
Query parameters
| Name | Default |
|---|---|
page | Optional |
size | Optional |
Example
Response: GenericResponsePagerBreakResponse
curl -X GET "https://api.bridgemoni.com/reconciliation/definition/value/break-queue" \
-H "Authorization: Bearer $BRIDGEMONI_TOKEN" \
-H "X-Tenant: $BRIDGEMONI_TENANT" \
-H "X-Environment: $BRIDGEMONI_ENV" {
"data": {
"content": [
{
"reference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"runReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"definitionCode": "string",
"breakKey": "string",
"category": "string",
"sideKey": "string",
"entityCode": "string",
"entryReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"externalReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"amount": "string",
"currencyCode": "string",
"valueDate": "string",
"status": "string",
"ageingStage": "string",
"ageBusinessDays": 0,
"firstSeenAt": "string",
"firstSeenRunReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"lastSeenRunReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"seenInRuns": 0,
"assignedTo": "string",
"assignedAt": "string",
"resolutionCode": "string",
"resolutionNote": "string",
"resolvedBy": "string",
"resolvedAt": "string",
"carriedReason": "string",
"instructionReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e"
}
],
"page": "1",
"size": "1",
"totalPages": "1",
"totalElements": "1"
},
"description": "Break queue retrieved successfully"
} Responses
| Status | When |
|---|---|
200 | Break queue retrieved successfully |
GET Read a definition's break queue
GET /reconciliation/definition/{code}/breaks
Every break this reconciliation has ever raised, with the age each has carried since it was first seen. A break that reappears in tomorrow's run is the same break one day older, not a new one - without that, a daily reconciliation resets every age to zero every morning and the queue can never escalate, which is the single most common way a reconciliation programme fails while appearing to work. Ages are in business days: a break raised on Friday evening is one day old on Monday.
Headers
| Name | Notes |
|---|---|
Authorization | Bearer token |
X-Tenant | Your tenant |
X-Environment | test or live |
Path parameters
| Name |
|---|
code |
Example
Response: GenericResponseListBreakResponse
curl -X GET "https://api.bridgemoni.com/reconciliation/definition/value/breaks" \
-H "Authorization: Bearer $BRIDGEMONI_TOKEN" \
-H "X-Tenant: $BRIDGEMONI_TENANT" \
-H "X-Environment: $BRIDGEMONI_ENV" {
"data": [
{
"reference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"runReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"definitionCode": "string",
"breakKey": "string",
"category": "string",
"sideKey": "string",
"entityCode": "string",
"entryReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"externalReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"amount": "string",
"currencyCode": "string",
"valueDate": "string",
"status": "string",
"ageingStage": "string",
"ageBusinessDays": 0,
"firstSeenAt": "string",
"firstSeenRunReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"lastSeenRunReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"seenInRuns": 0,
"assignedTo": "string",
"assignedAt": "string",
"resolutionCode": "string",
"resolutionNote": "string",
"resolvedBy": "string",
"resolvedAt": "string",
"carriedReason": "string",
"instructionReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e"
}
],
"description": "Breaks retrieved successfully"
} Responses
| Status | When |
|---|---|
200 | Breaks retrieved successfully |
GET Read the breaks a run raised
GET /reconciliation/run/{reference}/breaks
Missing on the internal side and missing on the external side are deliberately not one category called unmatched. One is money a counterparty says exists that we have not booked; the other is a payment we believe we made that they have never heard of. They go to different people and carry different urgency.
Headers
| Name | Notes |
|---|---|
Authorization | Bearer token |
X-Tenant | Your tenant |
X-Environment | test or live |
Path parameters
| Name |
|---|
reference |
Example
Response: GenericResponseListBreakResponse
curl -X GET "https://api.bridgemoni.com/reconciliation/run/b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e/breaks" \
-H "Authorization: Bearer $BRIDGEMONI_TOKEN" \
-H "X-Tenant: $BRIDGEMONI_TENANT" \
-H "X-Environment: $BRIDGEMONI_ENV" {
"data": [
{
"reference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"runReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"definitionCode": "string",
"breakKey": "string",
"category": "string",
"sideKey": "string",
"entityCode": "string",
"entryReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"externalReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"amount": "string",
"currencyCode": "string",
"valueDate": "string",
"status": "string",
"ageingStage": "string",
"ageBusinessDays": 0,
"firstSeenAt": "string",
"firstSeenRunReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"lastSeenRunReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"seenInRuns": 0,
"assignedTo": "string",
"assignedAt": "string",
"resolutionCode": "string",
"resolutionNote": "string",
"resolvedBy": "string",
"resolvedAt": "string",
"carriedReason": "string",
"instructionReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e"
}
],
"description": "Breaks retrieved successfully"
} Responses
| Status | When |
|---|---|
200 | Breaks retrieved successfully |
GET Read the ladder notes a run recorded
GET /reconciliation/run/{reference}/ladder-notes
Where the ladder found candidates and declined to choose between them. Two entries on one side for the same amount on the same day against one on the other is not a fifty per cent chance of being right; it is a question for a person, and answering it by iteration order gives a different answer on two runs of the same data. These notes are what turn 'unmatched' from a shrug into a finding.
Headers
| Name | Notes |
|---|---|
Authorization | Bearer token |
X-Tenant | Your tenant |
X-Environment | test or live |
Path parameters
| Name |
|---|
reference |
Example
Response: GenericResponseListLadderNoteResponse
curl -X GET "https://api.bridgemoni.com/reconciliation/run/b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e/ladder-notes" \
-H "Authorization: Bearer $BRIDGEMONI_TOKEN" \
-H "X-Tenant: $BRIDGEMONI_TENANT" \
-H "X-Environment: $BRIDGEMONI_ENV" {
"data": [
{
"reference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"runReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"stageLeg": "string",
"rung": "string",
"rungOrder": 0,
"matchedOn": "string",
"outcome": "string",
"candidatesLeft": 0,
"candidatesRight": 0,
"detail": "string"
}
],
"description": "Ladder notes retrieved successfully"
} Responses
| Status | When |
|---|---|
200 | Ladder notes retrieved successfully |
GET Read the matches a run committed
GET /reconciliation/run/{reference}/matches
Each match records the rung that fired and the key it fired on, so 'why did these two match' is answerable a year later without re-running anything. Rungs one to three are certain; four to seven are probable and may never auto-resolve whatever the tolerance says - a probable match auto-resolved is an unreviewed guess wearing a certificate.
Headers
| Name | Notes |
|---|---|
Authorization | Bearer token |
X-Tenant | Your tenant |
X-Environment | test or live |
Path parameters
| Name |
|---|
reference |
Example
Response: GenericResponseListMatchResponse
curl -X GET "https://api.bridgemoni.com/reconciliation/run/b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e/matches" \
-H "Authorization: Bearer $BRIDGEMONI_TOKEN" \
-H "X-Tenant: $BRIDGEMONI_TENANT" \
-H "X-Environment: $BRIDGEMONI_ENV" {
"data": [
{
"reference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"runReference": "b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e",
"stageLeg": "string",
"rung": "string",
"rungOrder": 0,
"confidence": "string",
"matchedOn": "string",
"amount": "string",
"currencyCode": "string",
"entryCount": 0,
"varianceAmount": "string",
"autoResolvedRule": "string",
"entryReferences": [
"b3f1c2d4-5e6a-4b7c-8d9e-0f1a2b3c4d5e"
]
}
],
"description": "Matches retrieved successfully"
} Responses
| Status | When |
|---|---|
200 | Matches retrieved successfully |
Generated from the OpenAPI document. Branch on the HTTP status: there is no machine-readable error code on the wire. Errors