Bank statement automation
Bank statement automation: the statement, matched to what explains it.
A converter turns a statement into rows. Automation is what happens next: each transaction matched against the period’s receipts and invoices, classified against your chart of accounts, and written up as double-entry postings, with the two remainders a reconciliation always has laid out for a human to settle.
Rows were never the hard part.
The bank exports a PDF. Someone converts it, and then the real work starts: which supplier was that card payment, which invoice did that transfer settle, why is the Alphamega line short by four euros, and what are the three receipts in the pile that no payment matches at all. A month of that for one company is an afternoon. For twenty clients it is the week.
Pileform reads the statement in the same run as the receipts and invoices, so the two sets can be married up. Transactions are classified in tiers: transaction-type defaults first, then a fuzzy match against the counterparties it already knows, then the chart of accounts, then you. What does not close is shown, not written off. The receipt and invoice half of that run is invoice automation; together the two make up the accounting software layer a Cyprus business keeps in front of its ledger, and the bookkeeping software a practice runs across twenty clients at once.
How a statement is worked.
Statements in the same drop
Add the statement PDFs to the period’s upload beside the receipts. Cyprus bank layouts, Greek-language layouts and international formats, digital or scanned, EUR, GBP and USD accounts in one period.
Every transaction extracted
Date, counterparty, amount, direction, running balance and a type hint per line, on a separate pipeline from the documents so a statement never gets read as an invoice.
Matched, then classified
Each payment is set against the documents that explain it. A supplier payment lands on that supplier’s tab. A partly explained payment shows the residue; a payment with nothing opposite it leaves a visible gap.
Posted as double entry
Confirmed transactions post as proper double-entry rows, not a one-column cash list, into Xero, QuickBooks, Business Central, BTMS or Esoft, or out to CSV.
The two remainders.
A reconciliation that only reports one remainder is hiding the other. Both are listed, neither is guessed.
- Money the documents do not explain
- Payments with no receipt or invoice against them, and payments only partly explained, with the shortfall shown
- Documents no payment explains
- Receipts and invoices in the period that no statement line settles, listed on their own
- Counterparty memory
- Each payee’s aliases and default codes are remembered per company, so the same card merchant is matched the same way next month
- Payment matching
- Payments allocated to invoices, across legs where one transfer settles several, with the allocation recorded
- Currencies
- A GBP account stays GBP and a USD card stays USD; nothing is silently converted
Where it earns its keep.
Practices closing many clients
Twenty statements a month, each against its own pile. Per-company counterparty memory means the second month is faster than the first.
Businesses with several accounts
A current account, a card, a foreign-currency account, all in the same period, all matched to the same documents.
Anyone preparing a VAT return
The statement and the documents that back the return, side by side, with the gaps visible before the return is drafted.
Bank statement automation, answered.
No. A statement is a file you already have, exported from your bank as a PDF. Pileform reads that file. It never connects to your bank and never moves money.
Statement PDFs from Cyprus banks, including Greek-language layouts, and international banks. Digital exports read cleanly; scanned or photographed statements are read too, with anything uncertain flagged rather than assumed.
It stays visible as unexplained, with the amount, and is classified against your chart of accounts by transaction type or by your rules so it still posts correctly. It is never written off and never assigned to a document that does not fit.
Double-entry rows in the same workbook structure as the receipts, grouped by counterparty, with proposed journal postings, plus the statement itself kept in the archive. Confirmed rows post to your ledger or export to CSV.
VAT lives on the document, not the payment. When a payment is matched to an invoice the VAT was already decided per line on that invoice, so the bank line carries the right net and VAT split through to the posting.
Put the statement in the same drop.
Sign up free, no card, and run one real month with the statements in it. The two remainders will be on screen before you have finished the coffee.