Payment approval was a per-invoice clerical check: read the PDF, match the supplier and IBAN against records, check the amount and look for duplicates, then hand-key a payment file. This system automates the clean cases end to end and puts only the exceptions in front of a person — with a full audit trail, and without ever moving money automatically.
pain.001 files for e-banking
Invoice-to-payment is high volume, low variance and unforgiving of mistakes. Most invoices are unremarkable and could be processed without human attention; a small minority are wrong, duplicated, or pointing at a bank account that does not belong to the supplier on the letterhead.
Clerical review treats all of them identically, spending the same two to three minutes on the boring ones as on the dangerous ones.
pain.001 payment file for e-banking, produced only from approved invoices.Nothing moves money automatically. The system prepares a payment file; a person approves it, and the bank executes it. Every automated decision along the way — every extraction, every validation, every routing choice — is recorded and attributable, because in finance operations an unexplainable automated decision is worse than no automation at all.
Shipped through the platform's nine milestones and an invoice-centric overhaul in six phases: roughly 40,000 lines of domain code, with batch upload through payment file working end to end on crash-resumable workflows.
Estimate, not a logged metric: a 50-invoice batch that previously required two to three minutes of clerical checking per invoice now runs unattended, with only flagged invoices needing an operator.
Note: this case study is deliberately written without client names, product names or customer data. Commit shares, code volume and milestone counts come from the repository; the batch-processing time saving is an engineering estimate.