Import the same bank statement twice without doubling the work

01

Make a repeated import recognizable

Begin by distinguishing a file from the transactions inside it. An identical file is one duplication case. A newly generated export covering some of the same days is another. A strategy based only on the file checksum will not address overlapping periods.

02

Establish transaction identity carefully

Use stable bank-provided identifiers when the supported format supplies them. Include account context so identifiers from separate accounts cannot collide. Where no reliable identifier exists, agree a matching approach using the available fields and identify the cases it cannot safely decide.

Two payments of the same value on the same date can be legitimate. A description may also change between exports. Treat uncertain matches as review candidates instead of deleting one record automatically. Preserve the source rows so finance can compare what the bank actually provided.

03

Separate import history from business records

Every upload should receive its own import record, including who submitted it and which format was used. Existing transactions can be referenced by several imports without being recreated. This preserves the fact that a colleague retried the operation while keeping the reconciliation ledger stable.

Show a preview with new, already known, changed and ambiguous rows. If an earlier transaction has updated details, identify the difference and define whether review is needed. Do not overwrite an approved reconciliation solely because a later file contains different free text.

04

Recover from interruptions without guessing

An upload may stop after only some rows have been saved. Store enough processing state to resume or safely replay the operation. The user should see whether the file was received, parsed, partly imported or completed, together with a reference support can investigate.

Stripe's idempotency documentation offers one example of a defined retry contract. Your importer needs its own contract suited to the destination system. Reusing an operation identity must not mean accepting a different payload without checking it. Detect that conflict and ask for a deliberate new import.

05

Keep decisions and access visible

A reviewer resolving an ambiguous duplicate should see both source rows and any existing allocations. Removing or merging a transaction can affect reconciliation balances. Require the appropriate finance permission and retain the reason, actor and previous relationships.

Restrict statement access by account and company. Import logs should help troubleshoot without exposing every counterparty. Use redacted files for development and agree how production data may be accessed during support. Export and deletion permissions deserve separate consideration from the ability to submit a file.

06

Test repeats that are genuinely different

Run an identical upload twice, then test overlapping periods, two equal payments and a file interrupted halfway through processing. Add a bank reversal and a later export with a corrected description. Verify both transaction counts and balances after every scenario.

Measure unresolved duplicate candidates and decisions that later require reversal. A successful test is not merely zero duplicate rows; it must also preserve every genuine movement. Finance should be able to explain why each row was created, reused, changed or held for review.

07

Distinguish a changed record from another payment

When two rows appear similar, ask which fields are stable identifiers and which may legitimately change. A booking description may become more detailed in a later export. A bank-provided transaction reference may remain stable. Record these assumptions for each supported format rather than applying one universal similarity score.

Show the reviewer the reason a pair was flagged and the consequences of each decision. Confirming a duplicate should reference the existing transaction; confirming a new payment should preserve both. If either already has allocations, those relationships must be visible before any merge or removal is approved.

Use an import report that reconciles every source row into a clear outcome: created, linked to existing, awaiting review or rejected with a reason. The total should match the source coverage for that import. A repeated file can then have a complete history even when it creates no new transactions. That is a successful recognizable retry, not an empty result that leaves the operator wondering whether anything happened.

• The importer distinguishes identical files, overlapping exports and legitimate equal-valued payments using the documented identity rules for each supported format.
• Ambiguous rows show the reviewer why they were flagged and whether either candidate already participates in an approved invoice allocation.
• Every source row has a reported outcome, including reuse of an existing transaction, a held review or a rejection with explanation.
• An interrupted import can resume without hiding its earlier work, and a repeated complete file explains why no new transactions were created.

08

Scope a dependable importer

RDC can build import identity, row-level matching, interruption recovery and the finance review interface for your supported statement formats. Start with the formats and repeat scenarios your team encounters today.

Provide redacted overlapping exports and the destination's record rules. We can define the acceptance cases and recovery behavior before implementation. The resulting proposal should name the supported formats, uncertainty handling and permissions, so repeat uploads become understandable events rather than another reconciliation problem.