A monthly reporting tool and a dashboard that tracks account activity through the day have different needs. Start with the decision your user has to make, then work back to how fresh the data must be.
At a glance
| CSV upload | Scheduled file | Bank feed | |
|---|---|---|---|
| Who starts it | A person, each time | A schedule | The integration |
| Typical freshness | Whenever someone uploads | Daily or weekly | Depends on bank and provider |
| Stable IDs | Rarely | Sometimes (e.g. OFX) | Ask the provider |
| Main failure | Forgotten or wrong file | Missed delivery, overlap | Expired access, failed sync |
| Your main work | Column mapping, previews | Overlap and ID handling | Connection states, recovery |
What a CSV workflow involves
In a file-based workflow, an authorised user exports transactions from online banking and uploads the file. Your application maps the columns, validates the values and records the rows.
This works well for an early product or an occasional reporting task. It also gives you a concrete file to inspect when something goes wrong. The cost is that everything depends on someone downloading and uploading the right export.
Show a preview before committing an import: the detected account, date range, row count and any rejected rows. Make users confirm ambiguous dates or columns instead of guessing. A date written 03/04 isn't safe to read without a known format.
Scheduled files and OFX
A middle option is a file that arrives on a schedule, such as a nightly CSV or OFX export dropped where your system can collect it. Bookkeepers who already run their own ledger often ask for exactly this. They want a predictable file with a stable transaction ID, not another login for their clients.
OFX helps because each transaction carries an identifier, FITID, intended to be unique within the account. Test whether it stays the same when the same period is exported twice before relying on it. Plain CSV exports often have no ID column at all.
Scheduled files still need everything below: overlap handling, a record of which file each row came from, and an alert when a file doesn't arrive.
What a bank feed changes
A feed removes the repeated uploads by fetching updates through an authorised connection. In exchange, your application has to manage connection state, data freshness and recovery when access or delivery fails.
Don't replace “last uploaded” with an unexplained green dot. Show when the feed last updated successfully, when it last tried, and whether the customer needs to act. The last successful sync is the first thing you need when a customer asks why a transaction is missing.
The provider's coverage and refresh behaviour must match your requirements. Our bank transaction API checklist lists the questions to ask before choosing one.
An overlapping-import example
A user uploads transactions for 1–7 October, then a second file covering 5–12 October. The files overlap by three days. Appending every row creates duplicates. Deleting everything in the overlap may remove real data and erase your import history.
| Date | Description | Amount | File 1 | File 2 | Decision |
|---|---|---|---|---|---|
| 5 Oct | Card purchase · Corner Café | −R 150.00 | ✓ | ✓ | Same row in both files: keep one |
| 5 Oct | Card purchase · Corner Café | −R 150.00 | ✓ | ✓ | A second, real purchase: keep both |
| 6 Oct | Client payment · INV-1042 | +R 4,800.00 | ✓ | ✓ | Same row in both files: keep one |
| 8 Oct | Monthly software | −R 319.00 | ✓ | New: import |
The first two rows show the trap. Two purchases can share a date, amount and description. Matching on those fields is evidence of a possible duplicate, not proof. Here the counts settle it: each file has two café rows for 5 October, so there are two purchases, not one repeated.
To handle this safely:
- keep an import-batch ID and the source row for every record, so you can always explain where it came from;
- use the bank's or provider's transaction ID where one exists;
- without IDs, compare counts of matching rows within the overlap, not just whether a match exists;
- flag uncertain matches for review instead of silently dropping them.
Feeds need duplicate handling too
Automation changes where repetition comes from. Retried notifications, repeated fetches and history backfills can all show your application the same activity again.
Keep the identity of an incoming event separate from the transaction it describes. One transaction can receive several updates, for example pending then posted. Record enough to apply each update once while keeping its history.
Importing is not reconciling
Getting a transaction into your system doesn't match it to an invoice or tell you what it means. Matching rules, exceptions and review are separate jobs.
A credit with an unfamiliar reference should not close an invoice just because the amount matches. Your application needs a stated matching policy and a place to inspect unresolved items.
Choose the smallest workflow that meets the need
Use CSV imports when manual updates fit the user's timing and you can make the import reliable. Consider scheduled files when users want automation and a predictable format. Evaluate a feed when repeated uploads become a burden or the product needs fresher data than files can give.
If you support more than one source, decide how they coexist before allowing overlapping data. A file import and a feed covering the same week will collide unless you've planned for it.
Where bankbuddy stands. The bankbuddy demo shows a transaction-feed interface using sample data. Live bank connections are still in development, and bankbuddy doesn't offer a CSV importer or reconciliation engine. Use the demo to explore the workflow, not to import real records.
Frequently asked questions
When is a CSV import enough?
When users need periodic updates and can reliably get the statement export themselves. Make the import preview clear, validate columns and dates, and explain rejected rows. Reconsider when repeated uploads become a burden or the product needs fresher data than people will realistically upload.
Do bank feeds eliminate duplicate transactions?
No. Repeated fetches, backfills and retried notifications can show your application the same transaction more than once. Use documented transaction IDs and a deliberate update policy. Track incoming events separately from the transactions they describe, so a later update isn't mistaken for a duplicate.
Is OFX better than CSV for ledger imports?
Often, because OFX includes a per-transaction identifier and a fixed structure, while CSV layouts vary by bank and rarely include IDs. Check that the identifier stays the same when you export the same period twice. If it changes, you still need overlap handling.
Can I use CSV imports and a bank feed together?
Yes, if your application defines how the two sources overlap. Keep source information and import history, use reliable IDs where available, and send ambiguous matches for review. Matching only on date and amount can merge separate transactions, so test with realistic overlap scenarios.
The dates, amounts and descriptions in this guide are synthetic examples.