Maciej Urbański

Work · FinOps

Settlement reconciliation across BLIK and POS

Monitoring that compares payment settlements with POS transaction streams so mismatches surface earlier across branch operations.

My role Tech lead / builder for the reconciliation pipeline and ops/finance shared view; coordinated with finance on what “mismatch” meant in practice.

Stack Python · SQL · BLIK settlement feeds · POS transaction data · operational logging · dashboard / alerts

Context
In a multi-site hospitality network, settlement accuracy is operational trust. BLIK settlements and POS transaction streams could disagree; finance and ops often discovered mismatches after the fact—sometimes deep into a later reconciliation cycle. Stakeholders: café ops, support, finance. Constraint: alerts had to be actionable, not noise, and could not require a new headcount watching dashboards all day.
Intervention

Delivered a reconciliation and monitoring path that joins BLIK and POS telemetry with operational logging for near real-time checks.

Phase 1 — Define mismatch semantics

Worked with finance/ops to define what counts as a mismatch vs. timing skew. Mapped fields across BLIK settlement exports and POS transaction streams so comparisons were apples-to-apples.

Phase 2 — Join + detect

Built Python/SQL jobs to ingest both streams, normalize keys (site, time window, amount), and flag divergences. Added operational logging so a mismatch could be traced back to source rows.

Phase 3 — Shared signal

Exposed a reconciliation dashboard/alert path shared by ops and finance—so anomalies become same-working-day signals (est.) instead of month-end surprises.

Risks & how they were handled
  • False positives from timing skew → windowed matching and explicit “pending settle” states.
  • Alert fatigue → tune thresholds with finance; prefer sparse high-signal alerts.
  • Sensitive payment data → least-privilege access; no broad distribution of raw feeds.
What I'd do differently
  • Instrument precision/recall of alerts earlier with a labeled sample week.
  • Add an explicit “known timing lag” playbook per payment rail.
Outcome
Before: settlement mismatches often waited for a later finance reconciliation cycle—commonly multi-day lag, sometimes toward month-end (est.). After: a reconciliation path combines BLIK and POS streams with operational logging for near real-time checks, so ops and finance typically see anomalies the same working day instead of discovering them after the fact (est.).

System map

POS + BLIK streams

multi-site

POS transactions

branch feeds

BLIK settlement

settlement feed

Reconcile

Detect and log

mismatch

Ops / Finance alert

shared

What it does

Surfaces mismatches before month-end

Logs the join for later audit

Shares one alert path with ops and finance

Near real-time settlement checks — find the mismatch while ops can still act.

What shipped

  • Reconciliation jobs Join BLIK settlement and POS streams across branches.
  • Operational logging Mismatch detection paired with payment telemetry.
  • Shared alert path Ops and finance see the same signal instead of a month-end surprise.

Stack Python SQL BLIK feeds POS data alerts

← LocalOutbound Next: Secure document AI →