Loading Settler...
Settler Blog
Deep dives into reconciliation infrastructure, integration patterns, audit evidence, and how Settler is built.
Same inputs, same rules, same outputs—every time. This is the core guarantee that separates a real reconciliation engine from a financial spreadsheet with an API. We break down what determinism means in practice, how we enforce it, and why it matters for audit, compliance, and debugging.
Every reconciliation run in Settler produces a SHA-256 hash chain over the evidence payload. Any post-run modification is immediately detectable. This post explains the evidence model, how the chain is constructed, and what it means for compliance workflows that need tamper-evident records.
Stripe processes payments. QuickBooks holds the books. The gap between them is where errors live. This guide walks through configuring a Settler job to reconcile Stripe payouts against QuickBooks journal entries, handling currency precision, partial matches, and refund timing differences.
Settler does not make autonomous financial decisions. Every flagged mismatch requires a human to inspect and resolve it. This post covers how we designed the review workflow—exception triage, AI-assisted context, documented resolution reasons, and audit-ready records of every human decision.
Financial data cannot leak between customers. This post details Settler's tenant isolation model: PostgreSQL row-level security, API key scoping, runtime isolation boundaries, and how we test for cross-tenant data leakage in CI. Built for the paranoid, by the paranoid.
Given stored inputs and the same ruleset, Settler can replay any historical reconciliation run and produce byte-identical output. This post explains how replay works, why it matters for debugging and audit, and how we verify replay integrity with hash comparison against the original evidence.
Topics
We publish technical deep dives for engineering and finance operations teams.
Get in touch