Advanced settlement review

Use the richer BP-1011 demo to inspect a seven-step pipeline: S3 settlement CSV and a PostgreSQL payment/refund ledger feed normalization, a nullable composite-key left join, batch totals and two separate PostgreSQL reporting upserts.

The comparison output branches into both a row-level report and grouped batch totals. This makes it useful for exploring Builder and same-run lineage beyond a single source/transform/sink chain. Missing ledger values remain NULL; they are not counted as zero discrepancies.

Set up and inspect

The canonical advanced recipe includes the lineage diagram, full specification, six saved-operation statements, logical bindings, CSV/SQL fixtures, reporting table definitions, expected results and independent destination checker. Follow its shared guide for Git import, environment validation, exact-version deployment and a manual run.

Use isolated S3 storage and separate PostgreSQL source/reporting databases. No BigQuery account is required for this executed demo variant. Its two sinks upsert by stable evaluation keys and require reporting tables without side-effecting triggers.

In Builder, follow read-settlement → normalize-settlement → compare-settlement, with read-ledger as the second comparison input. The comparison branches to write-comparisons and to batch-totals → write-totals. Open the completed run's full lineage and check all seven step outcomes, then independently read both reporting tables.

Results and evidence

Expect three comparison rows: a match, a refund difference of 500 cents and an unmatched line whose ledger/difference stay NULL. One total reports gross 11,000 cents, fees 350, net 10,650, matched ledger gross 8,000 and matched difference 500. The unmatched 2,500 cents remain a separate exception. These synthetic EUR-only calculations support investigation, not accounting correction or complete bank reconciliation.

The recipe preserves BP-1011's successful local rehearsal from 18 October 2026. Its exact spec, archived run identity and independent destination reads were rechecked on 19 October; public CLI alpha.6 passed fresh offline validation. This is historical execution evidence, not a new run, current target validation, hosted acceptance or completion of the demo film.

The two writes are independent and are not atomic. Inspect both tables after a partial write. Stable-key upserts do not remove records absent from changed inputs. See the canonical recipe for replay assumptions and cleanup, and all examples for compatibility and the simpler BigQuery reconciliation variant.