You've built an online wallet. Customers deposit money through Stripe. You record every deposit in your Blnk ledger, and Stripe settles the funds.

End of the week, your finance lead asks: "Can you confirm that every deposit we processed last week actually settled in Stripe, and that the net amounts match what we have in the ledger?"

If your honest answer is "I don't know," you need a reconciliation workflow.

Let's build a simple one together.

What reconciliation is (and why you should care)

Your Blnk ledger says one thing. Stripe says another. Reconciliation is just comparing both sides and making sure they agree, i.e. say the same thing.

Think of it as a trust check. Your ledger is the source of truth for what happened inside your product. Stripe is the record of what actually settled. Reconciliation closes the gap between the two, so you can confidently say: every dollar that came in is 100% accounted for.

Without it, problems pile up quietly:

• A deposit lands in Stripe but never gets recorded in your ledger. That's missing money.
• A ledger entry exists with no matching Stripe settlement. That's a ghost transaction.
• Stripe's net settlement is slightly different from what your ledger expected, maybe a rounding issue or a fee mismatch. That's a slow bleed you won't notice until the numbers are way off.

When reconciliation runs regularly, you easily catch mismatches before they snowball. Your finance team stops chasing you for answers. And if anyone asks how you verify your numbers, you can actually show them.

How Blnk Finance handles reconciliation

Now that you know what reconciliation checks for, here's how Blnk Finance actually does it. Three pieces work together:

• External data — Your Stripe data, formatted so Blnk can read it. You export your Stripe reports, map them into a structure Blnk understands, and upload them. This is what gets compared against your ledger.
• Matching rules — How Blnk decides if two records match. You pick which fields to compare (amount, reference, currency, date) and how much wiggle room to allow. This accounts for real-world messiness: timestamp drift, reformatted references, rounded amounts.
• Strategies — How Blnk knows the shape of a match. Not every reconciliation is a simple 1:1 comparison, so the strategy tells Blnk which pattern to expect:
  • One-to-one: One external record matches one internal record.
  • One-to-many: One external record is split across multiple internal records.
  • Many-to-one: Multiple external records are combined into one internal record.

Every reconciliation run combines all three: upload external data, pick a matching rule, choose a strategy, and let Blnk get to work.

Setting up the example

Let's say you run an online wallet called Pouch. Customers fund their wallets by depositing money through Stripe. Here's how a single deposit moves through the system:

1. A customer deposits $100.
2. Stripe processes the payment and takes its fee. The net amount (say, $97.10) is what actually settles.
3. Your Blnk ledger records the deposit using the unique Stripe payment ID (e.g., pi_3abc...) as the transaction reference. The customer's wallet balance receives the net settled amount

This ensures the same Stripe payment always maps to the same ledger record, giving you idempotency out of the box.

For this guide, we're focused on one question: does the net amount Stripe settled match what your ledger recorded?

Step 1: Preparing your Stripe data

To reconcile your Stripe records, you first need to import them into Blnk. To do this, we'll export the raw Stripe transaction reports. In this case, we'll export from the transaction table for a given period.

Blnk expects a CSV with these columns: id, amount, reference, currency, date, source, and description. Here's how they map to your Stripe data:

• id: A unique identifier for each external record.
• amount: Stripe amount
• reference: The Stripe payment identifier
• currency: "USD"
• date: UTC timestamp in ISO 8601 format, e.g. 2026-03-10T23:12:49Z. This one's important: if your dates aren't in this exact format, Blnk will treat them as different values and you'll get false mismatches.
• source: "Stripe"
• description: Optional. Leave blank or use Stripe's description.

For this example, the amount we use is the net settlement, not the gross charge. This is because the net Stripe amount is what we expect to be recorded in the ledger, so that's what we need to compare against.

Once your CSV is ready, upload it to your ledger in your Blnk Cloud dashboard.

Now Blnk has your Stripe data, but it doesn't know how to compare it against your ledger yet. That's where matching rules come in.

Step 2: Creating a matching rule

A matching rule tells Blnk which fields to compare and how strict each comparison should be. For our Stripe reconciliation, we will compare four things:

• amount · exact match — The net amount should match exactly. If your system records amounts consistently, there's no reason for a gap here.
• currency · exact match — Must be the same currency. Prevents false positives if you handle multiple currencies.
• reference · contains — The Stripe payment ID should appear somewhere in the ledger transaction's reference. We use "contains" instead of "equals" because your ledger reference might wrap the Stripe ID with a prefix or suffix. For example, Stripe gives you pi_3abc, but your ledger stores the reference as pi_3abc_deposit. "Contains" still finds the match.
• date · equals, 30-minute drift — Timestamps won't always line up perfectly between Stripe and your ledger. A 30-minute window covers the gap.

You'll notice the date criteria uses something called drift.

Drift is the tolerance window Blnk applies to date and amount fields. Here, we used 30 minutes (1800s) on date, i.e. both timestamps can be up to 30 minutes apart and still match.

Step 3: Running the reconciliation

With your data uploaded and matching rule ready, you can now run the actual comparison. Head to the Reconciliation section in Blnk Cloud.

• Select the Stripe data set you uploaded.
• Set the strategy to one-to-one. Each Stripe settlement record maps directly to one ledger transaction.
• Pick the matching rule you just created.
• Run the reconciliation.

Blnk will compare every record in your Stripe data against your ledger transactions using the criteria you defined. Each run gives you a summary of matched and unmatched records.

Here's how to read them.

Step 4: Reading and acting on results

After the reconciliation run, you'll see a breakdown of matched and unmatched records

Here's how to interpret them.

Matched records

Every matched ledger transaction is automatically tagged as Reconciled in its metadata. This confirms that Stripe and your ledger agree on that deposit.

You can filter for reconciled transactions in the dashboard to see the full list.

Unmatched external records

These show up directly in the reconciliation results. They mean Stripe has a settlement record that your ledger doesn't. Common causes:

• The deposit was never recorded in the ledger (a webhook was missed, or processing failed silently).
• The reference didn't carry over correctly. Check for typos, formatting differences, or missing prefixes.
• The amount or date fell outside the matching criteria you defined.

Unreconciled ledger transactions

These are the inverse: ledger entries with no matching Stripe record. They won't appear in the reconciliation results directly. You need to filter for them separately in the Transactions tab by looking for transactions where reconciled does not exist in the metadata.

Common causes:

• The Stripe export was incomplete or didn't cover the full date range.
• A test or duplicate transaction was recorded in the ledger but never actually processed by Stripe.
• The transaction's reference was modified after recording and no longer matches the Stripe side.

What to investigate first

Focus on unmatched external records.

These are Stripe settlements that have no matching entry in your ledger, meaning real money came in but your system doesn't know about it. That's more urgent than the reverse (a ledger entry with no Stripe match), because it means your books are understating what actually happened.

When you're looking at an unmatched record, check these in order:

• Reference: This is the most common culprit. The Stripe payment ID might not have carried over correctly into your ledger's reference field. Look for typos, missing prefixes or suffixes, or formatting differences between the two systems.
• Date: If your external data timestamps aren't in the exact UTC ISO format Blnk expects, or if the timing gap between Stripe and your ledger exceeds the drift window you set, the records won't match even if everything else lines up.
• Amount: If the reference and date look fine but the amount is off, check how your system calculates the net settlement. A mismatch here usually points to a fee calculation issue or a rounding difference.

Once you've resolved every unmatched record and both sides show zero mismatches, you've confirmed that every deposit Stripe settled is accounted for in your ledger.

With this workflow in place, your team can reconcile weekly or daily, and confidently answer that end-of-week question from finance.

What else can you reconcile?

Once you have the reconciliation pattern down, you can extend it to:

• Gross amount reconciliation: Compare the full deposit amounts before Stripe fees, useful for verifying your ledger captures the complete picture.
• Fee reconciliation: Verify that the Stripe fees your ledger recorded match what Stripe actually charged.
• Multi-provider setups: If you accept deposits through Stripe and another provider, run separate reconciliation workflows for each and cross-reference.
• Payout reconciliation: Match Stripe payouts to your bank against your ledger.

With this workflow in place, your team can reconcile weekly or daily, and confidently answer that end-of-week question from finance.

Ready to start?

• Check out the demo

• Set up your Blnk Cloud instance and run your first reconciliation.