
Accounting & Bookkeeping · Payments · E-commerce Operations · Professional Services
Multi-Channel Payment Reconciliation and Accounting Import Automation
- Client
- Accounting firm · Bulgaria · books for an international data centre and hosting provider
- Industry
- Accounting & Bookkeeping
- Department
- Finance & Accounting
- Region
- Bulgaria
Card, PayPal, bank wire and two crypto channels, each settling in batches days later and hopping through intermediary accounts. Every month an accountant lost 3-4 days working out which order sat inside which deposit, and one mismatch meant unpicking the whole month. Now the month reconciles itself and lands in the accounting software as a ready import file.
A working model of the approach on sample data. It plays on its own and pauses when scrolled away; nothing here touches a live system.
The results
- 600
- invoices booked in a single monthly run
- 1,778 accounting lines, 0 system errors.
- 95%
- of bank statement lines handled automatically
- 100% of invoices processed.
- ~3 mo
- to pay for itself
- 3-4 accountant days removed every month.
The challenge
Our client is a small Bulgarian accounting firm. The business behind this automation is one of its clients: a data centre and hosting provider selling online to customers around the world.
It takes money five ways, and none of them settles one order at a time. A card processor batches a day of sales into one payout. PayPal sweeps into Wise. A crypto exchange wires one amount days after selling a basket of coin, for more or less than was invoiced. Money hops through intermediary accounts before it ever reaches the bank. The books live in AJUR, a legacy Bulgarian accounting system with no API, which accepts data only through its own import file.
Every month an accountant sat with seven exports open, worked out which orders sat inside which deposit, classified every outgoing payment, applied the right VAT treatment for each customer, then typed each result in, one journal entry at a time.
What it was costing them
- 3-4 working days a month of an accountant, in a two-person firm.
- Fragility. One mismatch found later meant unpicking a month of entries.
- No leverage. The work grew with the client's order volume, not with the accounting fee.
- Crypto risk. Exchange-rate differences between invoice and sale were easy to lose or to book wrongly.
- Card (Stripe) → Bank account
- PayPal via Wise → Bank account
- Bank wire → Bank account
- CoinGate → Bank account
- Kraken (BTC, LTC) → Bank account
The approach
We built an unattended monthly reconciliation and booking system on a self-hosted n8n platform. One project: the matching and the accounting import are the same automation.
Seven sources, one shape
PayPal, Wise, two Stripe exports, the CoinGate ledger and two bank statements are read and normalised into a single internal format, whatever encoding or layout each provider ships. The master order register is the starting point for every order, and its payment method decides which matching route applies.
Five matching engines, one per payment route
| Route | How an order is matched |
|---|---|
| Card (Stripe) | Order, balance movement, payout, bank deposit, by amount and date inside a 5-day window |
| PayPal | Order, daily PayPal withdrawal, Wise deposit, inside a 5-day window |
| Bank wire | On the customer reference carried in the payment description |
| CoinGate | Order, next withdrawal on or after the order date, exact-amount bank deposit |
| Kraken (BTC, LTC) | By transaction-code prefix, because the bank truncates the code |
Following the money
- Every hop through an intermediary account is traced and booked, so the trail runs order, processor, intermediary account, bank line, accounting entry.
- Crypto price differences between invoicing and sale are booked automatically to exchange gains or losses.
- VAT by customer. Every invoice is checked for customer location and type, business or private, and the domestic, EU or non-EU treatment follows.
- Multi-currency conversion and supplier-to-account mapping per transaction.
Every outgoing payment, classified
Outgoing bank lines run through ordered rules, first match wins: bank fees, internal transfers, the tax authority, salaries and related-party movements are identified first; everything else is classified to a supplier account by the counterparty's bank country: domestic, EU, outside the EU, cash withdrawal or bank charge. Card payments carry no counterparty IBAN, so their country is derived from the merchant description. Anything that reaches the end of the rules is listed for checking, never defaulted silently.
The import file a legacy system accepts
AJUR takes nothing but its own file: a custom delimited format with a specific encoding, block structure and sequential registration numbers. Every reconciled transaction becomes a debit and credit entry in exactly that format. The automation prepares and delivers the file; the accountant imports it and stays in control of what is posted and when.
- Safe to re-run. A re-run regenerates the full month under a new batch rather than a delta that could collide with numbers already imported. Earlier batches are kept as history.
- Reporting. A monthly report gives every transaction its status, match and accounting entry, with flagged rows separated into a review queue.
- Seven sources, one format
- Five matching engines
- Intermediary hops traced
- VAT by customer
- AJUR import file
Technology
| Layer | What we used |
|---|---|
| Orchestration | n8n, self-hosted |
| Sources | Stripe, PayPal, Wise, CoinGate, Kraken and bank exports |
| Workspace and configuration | Google Drive with n8n service connectors, Excel owned by the accountant |
| Rules | Matching engines, VAT rules, ordered supplier classification, multi-currency |
| Accounting system | AJUR, through its native import format |
The outcome
| Before | After | |
|---|---|---|
| Monthly close | 3-4 accountant days | One unattended run |
| Invoices processed | By hand | 100% |
| Bank statement lines | Classified by hand | ~95% automatically |
| Journal entries | Typed one by one | A file the accounting system imports directly |
| Payback | About 3 months |
- 600 invoices and 1,778 accounting lines produced in one monthly run, with 11 rows left for review and 0 system errors.
- 100% of invoices processed; about 95% of bank statement lines handled automatically.
- 3-4 days of accountant work removed every month. The automation paid for itself in about three months.
- Every order traceable end to end: order, processor, intermediary account, bank line, accounting entry.
- Ambiguity is visible, never guessed. Anything the data cannot settle is flagged with its reason on the row.
- The same configuration and exception framework now serves more than one of the firm's clients.
- Status, match and entry per line
- 600 invoices, 1,778 lines
- 11 rows flagged for review
- 0 system errors
The risk most teams miss
Payment providers change their export formats, and new channels and intermediary accounts appear. Without an owner for the configuration, match rates fall quietly. Here every rule and every account lives in a workbook the accountant controls.
Built with
The tools this ran on, by the layer each one carried.
- Apps & integration
StripePayment processor whose payouts we reconcile to orders and bank lines.
PayPalWallet payments reconciled into the books.
WiseMulti-currency account exports reconciled into the books.- AJURBulgarian accounting software, fed through its native import format.
PayseraPayment account whose statements are reconciled into the books.
CoinGateCrypto payment processor reconciled to orders and bank payouts.
KrakenCrypto exchange whose settlements are matched by transaction code.
- Automation
- Data & cloud
Next step
Start the same conversation
Tell us the process that keeps breaking. We will come back with what it would take to fix it, what it would cost, and what we would measure.
Or write to us directly: •••••@•••••••.•••
- A reply from a partner within one business day
- Fixed scope and fixed fee, agreed before we start
- The maps and the backlog are yours either way



