Bank Feeds
Part of Accounting integrations
Monitoring errors between accounting and operational systems
Find missing, rejected, duplicate and misposted integration entries with source references, total checks and a controlled correction path.
Monitor an accounting integration by checking both delivery and financial results. A transfer can fail visibly, arrive late, arrive twice or post successfully to the wrong account. Each case needs a source reference, a clear owner and a way to correct the ledger without losing the history.
Define what should arrive
List the events each connection is expected to send: a closed POS shift, a provider payout or an approved payroll run, for example. For each event, record its source identifier, destination identifier, amount or totals, expected frequency and acceptable delay. That basis helps find missing items as well as rejected ones.
Keep separate views for transport errors and accounting differences. A transport error means the item did not reach its destination as intended. An accounting difference means it arrived but does not agree with the source or reconciliation. A connection-status indicator may reveal the first and miss the second.
| Signal | First check |
|---|---|
| Missing item | Was it created and approved in the source, and has its expected delivery time passed? |
| Rejected item | Which field or permission failed, and was any entry created? |
| Duplicate-looking item | Do source and destination references show one event delivered more than once? |
| Total mismatch | Do report dates, currencies, refunds and fees explain the difference? |
| Old clearing balance | Is money still in transit, or was a payout or correction missed? |
Give exceptions a controlled path
Assign each alert to a person who can inspect both systems. Record when the issue was found, the affected period, the source and ledger references, its financial impact and the decision made. A support ticket can track the work, but the accounting correction needs its own traceable entry and approval.
Before a retry, determine whether the first attempt posted anything. Re-sending an uncertain batch can create duplicate revenue, expenses or payroll entries.
If the destination entry exists, compare it with the source and correct that entry through the approved process. If no entry exists, replay the event with the same source identifier where supported, then verify the result.
Use periodic count and total comparisons as well as event alerts. For example, compare the number of approved pay runs or closed shifts with imported journals, then reconcile their component totals. Differences around period-end deserve attention even when the connection later catches up, because the entry may have landed in another reporting period.
Review patterns, not just individual alerts
Group repeated failures by cause: changed account mapping, expired access, new payment type, altered export format or a source record lacking required detail. Confirm the cause before changing configuration, and inspect earlier items affected by the same rule. Retain a record of the old and new mapping and who approved the change.
Set a review rhythm that matches the volume and risk of each flow. A high-volume sales feed may need frequent exception checks; a monthly journal needs review when the run is approved and again at close. Australian record-keeping guidance requires business records to remain accessible and protected, so preserve source reports and correction history alongside the monitoring log.
Key Monitoring Metrics for System Integration
- Expected Frequency
- e.g., daily closed POS shifts, monthly payroll runs
- Total Reconciliation Check
- Compare count and totals of events across systems (e.g., pay runs, shifts)
- Australian Record-Keeping Requirement
- Records must be accessible, protected and retained per ATO guidelines
