Pulling Bank and Card Transactions for Reconciliation: The Options That Actually Exist

An Israeli business has five realistic routes to bank and card transactions: a licensed financial information service provider, a manual export from the bank's site, a file produced by the accounting software, settlement reports from the acquirer, and the API of the payment provider the money arrives through. They differ in history depth, stability, and who owns the failure.

Five routes, and what each really delivers

The first two rows answer "what went into and out of the account". The last two answer "who paid me and when did the money actually land", which is a genuinely different question - see the comparison of Israeli payment gateways.

Why a manual export is still the right first build

A regulated route through a licensed provider needs a contract, an access consent and time. It is also obliged only to the 12 months preceding the request, per Proper Conduct of Banking Business Directive 368. A business that opened five years ago and wants to reconcile two years back will not get that from any interface.

A manual export, by contrast, is available today, produces exactly the period you need, and costs an hour of work. More importantly, it forces you to write the matching engine before spending anything on integration. If the engine cannot match a hand-exported file, it will not match an automated feed either - only more slowly and at higher cost. Plan the transition so that the data source is a replaceable component and the engine survives it.

How do you give a bank transaction a stable identity?

There is no uniform natural identifier for an Israeli bank transaction. The reference number in an export is not necessarily unique over time, not necessarily stable across channels, and sometimes repeats between accounts. So you mint a local key:

1. Pick fields that do not move. Account number, value date, amount, debit or credit sign, and a normalised description.
2. Normalise the description. Double spaces, gershayim and RTL control characters are a permanent source of difference between two pulls of the same transaction.
3. Add a counter for genuine duplicates. Two identical expenses on the same day are reality, not a bug. The key needs an ordinal within the day.
4. Freeze the key at first ingest. If a change to the normalisation rules alters an existing key, every historical match detaches.
5. Keep the raw row. The text as received, alongside the parsed fields, so a mismatch can be investigated without pulling again.

The same need recurs across financial integrations, including the account-number problems described in bank account check digits and payment rejections.

Alongside a key per transaction, log the pull itself: which source, which date range, how many rows came back and how many of those were new. That record answers the question that returns every month end - "is the transaction missing, or was it simply never pulled" - and without it every investigation starts with another pull that only muddies the picture. A pull that returned zero new rows is information rather than a failure, and the screen should present it that way.

The gap between a bank line and a bookkeeping line

• Timing. The card transaction date, the aggregated bank charge date and the invoice date are three different dates for one event.
• Aggregation. The bank shows one aggregated charge; the card shows dozens of transactions. A one-to-one match does not exist, and anyone who builds one manufactures discrepancies.
• Refunds. A credit is usually recorded as a new transaction rather than a reversal of the old one, so the engine has to link the pair itself.
• Currency. A foreign-currency charge arrives already converted, sometimes with the conversion fee on a separate line.
• Fees. Processing fees are deducted before the money lands, so the amount hitting the account never equals the invoice amount.

Those five gaps are why a hundred percent automatic match rate is not a sensible target. A sensible target is that every unmatched transaction lands on an exceptions list with a readable reason, and that the list shortens month over month as the rules sharpen. A business measuring itself on match rate alone tends to loosen rules until they match the wrong things, which is worse than a visible discrepancy somebody closes by hand.

Which route suits a twenty-person business?

In practice a sequence, not a choice: first a monthly manual export from the bank and the card to stabilise the engine and the history, then the payment provider API to close the revenue side in near real time, and only then a licensed provider for a daily bank feed. That order holds because each stage delivers value even if the next stage is never built.

The daily process that sits on top of the feed is described in daily bank reconciliation in a small business.

What to have ready before starting

• A decision on how many months back you need, as a number rather than "as much as possible".
• The list of accounts and cards genuinely in scope, including personal cards used for business.
• A definition of what counts as a match: exact amount, an amount range, or amount plus date within a window.
• Somewhere to park an unmatched transaction, with a reason, so it does not vanish until the next review.
• Who approves a manual match, and where that is recorded.

Sources

• Proper Conduct of Banking Business Directive 368 - Implementation of an Open Banking Standard in Israel, Bank of Israel
• Financial information service - Israel Securities Authority