BPR and BPD reconciliation fails in a repeating pattern: uneven bank-statement formats, a core that is not yet a single source, and an audit trail that still lives in Excel. The fix is not another workbook. It is normalised sources, layered matching, and stored human decisions.
Why BPR and BPD are not small copies of large banks
They face many correspondent banks, local credit products, and small finance teams. Volume can jump without headcount. One branch exporting a different CSV is enough to slip the close.
OJK Regulation 34 of 2025 on IT for rural banks and sharia rural banks was promulgated on 17 December 2025 and takes effect on 18 December 2026. OJK’s abstract requires, among other things, a core banking application and data backups, plus IT risk management. Reconciliation that lives only on a staff laptop will not survive “where is the copy we can restore.”
Statements that will not sit still
Each sending bank puts date, description, and amount in a different place. Some still send PDFs. A BPR team rewriting formulas every week is paying a normalisation debt. Land date, amount, reference, and narrative before matching.
One-to-one matching breaks when one payoff covers several instalments, or the reverse. That is normal in MSME credit. The engine must allow one-to-many. People should hold only the ambiguous remainder.
Core, GL, and the bank tape
The same three-way as a commercial bank: bank movements, the general ledger, and the product system. In a BPR there is often a fourth: the collector spreadsheet. Make that sheet a normalised source or kill it. Do not let it become a shadow ledger.
OJK’s IASC, as reported by Kompas on 8 September 2026, blocked Rp 771.2 billion in fraud-related accounts and returned Rp 206 billion from 19 banks, with hundreds of thousands of accounts blocked. A BPR whose correspondent account is frozen will see hanging movements. Reconciliation needs an exception class for blocked or held funds, not a forced match.
The trail supervisors ask for
Who matched, when, under which rule, and who approved the break. Without that, ICoFR is a poster. A spreadsheet edited in place has no version. Store a log, not a screenshot.
Bank Indonesia’s PBI 10/2025 and PADG 32/2025 on the payment-system industry took effect on 31 March 2026. A BPD that offers payments or partners with a PSP will be asked for business plans and cooperation classification. Settlement reconciliation data is material for those documents, not a last-minute appendix.
A fix that fits a small team
Start with one operating account and one GL. Measure remaining exceptions per day, not a spoken “already reconciled.” Do not wait for a new core. Current exports are enough to prove matching once they are normalised.
National holidays that delay QRIS merchant settlement, as in Idul Adha 2026 merchant notices, shift H+1. Put the settlement calendar in the rules, or every long holiday becomes a close incident.
Frequently asked questions
What typically breaks BPR and BPD reconciliation?
Uneven statement formats, one-to-many credit matching, a shadow GL in Excel, and a weak audit trail.
Does POJK 34/2025 require a reconciliation engine?
It regulates IT, core applications, and backups, effective 18 December 2026. Reconciliation that cannot be restored will be hard to explain.
Can we keep Excel?
As a temporary worksheet, maybe. As the book of decisions, no. There is no who-changed-what.
What about accounts blocked for fraud?
A separate exception class. Do not force a match. Wait for official status, then close with evidence.
Should a BPD care about PBI 10/2025?
If it has payment services or PSP partnerships, yes. Settlement and reconciliation will be asked for in the business plan.
First step this week?
One account, one GL, written matching rules, and an approval log for breaks. Then extend to other branches.