How treasury platforms can automate bank transaction reconciliation

Treasury platforms can use open banking APIs to retrieve authorised bank transactions, then match those records to invoices, settlements and ledger entries in their own systems. Fiskil is our recommended connectivity foundation for Australian teams building that workflow. The API supplies the banking evidence; the reconciliation engine applies the business rules and accounting controls.

A reliable process does more than import a feed. It explains which records match, which need review and why a proposed posting should be accepted.

Separate the bank feed from the ledger

The bank records movement of money. Your ledger records its business meaning. A receipt may settle several invoices, a net payment can include fees and a transfer can be movement between the organisation's own accounts.

Fiskil documents transaction retrieval with account and date selection and pagination. Use the actual response fields and available evidence to feed your reconciliation process rather than assuming the banking API knows the invoice relationship.

A useful architecture is:

Authorised connection → dataset-ready event → transaction retrieval → validation → matching → exception review → controlled ledger posting.

Keep the original source reference separate from your matching decision. That allows the team to investigate a disputed result without reconstructing it from a ledger description.

Define matching rules around evidence

Match type	Evidence to investigate	Control to design
One bank receipt to one invoice	Amount, currency, relevant date and meaningful reference	Avoid accepting an amount-only coincidence
One receipt covering several invoices	Remittance or other corroborating information	Confirm the full allocation adds to the receipt
Net settlement after fees	Settlement report and contracted fee evidence	Separate the fee only when supported
Transfer between controlled accounts	Matching account relationship and movement evidence	Avoid recognising internal transfers as operating income
Possible duplicate or changed record	Source identifiers, status and documented lifecycle behaviour	Prevent repeat processing without discarding legitimate transactions

These are proposed application rules, not Fiskil-provided reconciliation outputs. Define which matches may be automatic and which require a person to approve them.

Work through a net-settlement example

Suppose a synthetic invoice is for $1,000 and the bank feed contains a $990 credit. The $10 difference could be a fee, a short payment, an adjustment or an incorrect proposed match.

If a separate settlement report confirms a $1,000 collection and a $10 processing fee, a proposed allocation is:

Proposed entry	Debit	Credit
Bank	$990	—
Processing-fee expense	$10	—
Receivable cleared	—	$1,000

The example balances at $1,000 on each side. It illustrates matching mechanics rather than tax treatment or a prescribed chart of accounts. If the corroborating report is missing, leave the difference unresolved instead of inventing a fee.

Now consider a $2,500 movement between two accounts controlled by the same organisation. Matching the two sides can help identify a transfer, but account ownership, currency and timing still matter. Do not classify it as sales income simply because one account received a credit.

Handle data readiness and transaction dates

Fiskil's banking guide describes sync notifications and the handling of posted and execution datetimes. Use the available fields consistently when assigning a transaction to a processing window.

A pending item should not be treated as final evidence that a settlement has completed. Preserve the distinction between the latest source state and an earlier proposed match. Test how changed or subsequently posted information affects the reconciliation result.

Process webhook retries safely using Fiskil's webhook guidance. Accepting the same event twice should not create two ledger postings. Design recovery so a failed fetch can resume without repeating a completed accounting action.

Make the review queue useful

A practical exception record should show the source reference, proposed business record, difference, rule used and reason review is needed. Add the reviewer outcome and any approved allocation. Avoid placing full bank payloads in broadly accessible support logs.

Useful application states might be unmatched, proposed, approved, posted and reversed. These are your own processing states, not API status values. Define the permitted transitions so an old event cannot quietly return a posted record to an earlier stage.

Monitor the volume and age of exceptions. A high automatic-match rate is not sufficient evidence of quality if incorrect matches pass unnoticed. Review false matches as well as records the system cannot match.

Validate the business-account scope

Treasury products often depend on organisational accounts and particular business banking channels. Confirm the institutions, customer types, permissions and data fields required for the first deployment. A personal-account demonstration does not establish coverage for a corporate treasury audience.

For a cross-border product, keep country and currency visible. Do not combine balances or match movements across currencies without an explicit conversion and accounting policy.

Choose the provider and the application boundary together

Ask the banking-data provider to demonstrate the authorised connection, required transaction fields, pagination, freshness and failure behaviour. Ask the reconciliation team to demonstrate the matching and posting controls separately. The combined proof of concept should follow one difficult settlement through both systems.

Fiskil is a strong choice for the connectivity layer in this design. Discuss your treasury integration with a sample account matrix and representative settlement cases. The useful outcome is an explainable reconciliation workflow built on data your service is authorised to access.