Reconciliation product semantics
Operator- and integrator-facing meanings for session behaviour: schedules, templates, merge/overwrite, duplicates, corrections, reruns, and unmatched states.
Purpose
Explain what the knobs mean when starting or continuing a reconciliation session — without service-level deployment detail.
Scheduled reconciliation
| Topic |
Meaning |
Status |
is_scheduled on the request |
Marks the run as schedule-triggered |
Coded (flag) |
| Period when dates omitted |
Ingestion can derive the period when the flag is set |
Coded |
| In-product cron / scheduler |
Who fires the HTTP start is outside the AI reconciliation package |
Not claimed — confirm with MasteryHive how your environment schedules jobs |
Source connections
| Topic |
Meaning |
Status |
| Input model |
Sessions take file URLs (GL / bank or asset extracts in object storage) |
Coded |
| Named “source connections” (SFTP connectors as product objects) |
Not evidenced as first-class objects in the AI reconciliation package |
UNVERIFIED — treat file URL supply as the supported pattern |
Sample / matching templates
| Topic |
Meaning |
Status |
template / settings on the request |
Matching configuration for the session; settings override template |
Coded |
| Named template catalog / CMS |
No separate template product catalog verified |
UNVERIFIED as a catalog — programmes may still use agreed template payloads |
See also Report templates guide.
Merge versus overwrite versus stop
| Mode |
Meaning |
| Merge |
Combine into existing data for the scoped upload (ETL-specific behaviour) |
| Overwrite (common default) |
Replace scoped prior data for the partner / tenant / period (exact wipe scope is vertical-specific) |
| Stop |
Do not mutate when conflicting data already exists |
Concurrent sessions for the same period can be blocked by a period lock (caller sees a conflict). Confirm wipe scope with MasteryHive before production overwrite runs.
Duplicate prevention
| Layer |
Behaviour |
| Pipeline triggers |
Duplicate stage triggers for the same session are ignored for a time window |
| Matching |
Same-side surplus rows can be flagged as duplicates; cross-side same session+amount can match |
| Period lock |
Prevents competing active sessions for the same period |
Rerun tip: after a failed run, prefer a new session_id rather than replaying the same id into a still-guarded pipeline.
Corrections and reruns
| Mechanism |
Use when |
| Overwrite mode |
Replace prior results for the scoped period |
Resume fields (existing_session_id, last_processed_step) |
Continue a prior run where supported |
| Reprocess unmatched |
Match current unmatched against a prior session’s unmatched (lookback applies) |
| Dedicated “correction” product API |
Not a separate named API — use the mechanisms above |
Unmatched states
| State |
Meaning |
| Unmatched GL / bank |
Lines that did not find a counterpart |
| Matches |
Lines treated as reconciled |
| Exception clusters |
Groups of anomalies for operator decision (detect availability depends on path — not every fan-out path auto-detects) |
Resolve decisions (approve, reject, escalate, reopen, reconcile) update exception state and leave an audit record — see Exception resolve.
Completion semantics
| Signal |
Meaning |
| Pipeline / session status |
Progress through ingest → match → load |
| Batch completion |
Matching windows finished (including recovery for stalled batches) |
| Exception resolve complete |
Operator decision recorded — not the same as “all unmatched cleared” |