Accounting practice · Bulgaria · client: international data centre and hosting provider
Five Payment Channels Reconciled and Booked to AJUR Every Month
Customers paid by card, PayPal, bank wire or one of two crypto channels. Each paid out in batches days after the sale and passed through intermediary accounts on the way. An accountant spent 3-4 days a month tying orders to deposits, and one mismatch could force the whole month to be redone. Today the month reconciles without help and reaches the accounting software as an import file ready to load.

- Industry
- Accounting & Bookkeeping
- Function
- Finance & Accounting
- Region
- Bulgaria
Results
- 600
- invoices posted in one monthly run
- 0 system errors across 1,778 accounting lines.
- 95%
- of bank statement lines processed with no manual work
- Every invoice processed: 100%.
- ~3 mo
- payback period
- Saves 3-4 days of accountant time each month.
01
The challenge
The client is a small accounting firm in Bulgaria. The automation serves one of the firm's own clients, a data centre and hosting provider that sells online to customers worldwide.
That provider gets paid through five channels, and none of them pays out order by order. The card processor rolls a full day of sales into a single payout. PayPal moves funds on to Wise. A crypto exchange sells a basket of coin and wires one sum days later, often above or below the invoiced amount. Before money reaches the bank it passes through intermediary accounts. The ledger is kept in AJUR, an older Bulgarian accounting system that has no API and takes data only through its own import file.
Each month, an accountant opened seven exports side by side. They matched orders to deposits, sorted every outgoing payment, worked out the correct VAT treatment per customer and then keyed in the results, entry after entry.
The real cost
- 3-4 accountant days every month, in a firm of two people.
- Brittle books. A mismatch spotted later forced a month of entries to be taken apart.
- No economies of scale. Effort tracked the client's order volume, not the fee the firm charged.
- Crypto exposure. The rate gap between the invoice and the coin sale was easy to miss or to post wrongly.
02
What we did
We delivered a monthly reconciliation and booking system that runs unattended on self-hosted n8n. Matching and the accounting import are not two projects. They are one automation.
Seven inputs, one format
We read two bank statements, two Stripe exports, PayPal, Wise and the CoinGate ledger, and convert each into one internal format regardless of the encoding or layout the provider uses. Every order starts from the master order register, and the order's payment method picks the matching route.
A matching engine for each payment route
| Payment route | Matching logic |
|---|---|
| Card (Stripe) | Order to balance movement to payout to bank deposit, on amount and date within a 5-day window |
| PayPal | Order to daily PayPal withdrawal to Wise deposit, within a 5-day window |
| Bank wire | Customer reference found in the payment description |
| CoinGate | Order to the first withdrawal on or after the order date, then to a bank deposit of the exact amount |
| Kraken (BTC, LTC) | Prefix of the transaction code, since the bank cuts the code short |
Tracing every hop
- Each pass through an intermediary account is followed and booked. The trail runs from the order through the processor and the intermediary account to the bank line and the final accounting entry.
- Crypto price gaps between invoice and sale post automatically to exchange gains or losses.
- VAT per customer. We check each invoice for where the customer is based and whether it is a business or a private person, then apply domestic, EU or non-EU treatment.
- Multiple currencies. Each transaction gets currency conversion and a supplier-to-account mapping.
Sorting outgoing payments
Outgoing bank lines pass through rules in a fixed order, and the first rule that fits wins. The first rules pick out bank fees, internal transfers, salaries, tax authority payments and related-party movements. The rest go to a supplier account based on the country of the counterparty's bank: domestic, EU, non-EU, a cash withdrawal or a bank charge. Card payments have no counterparty IBAN, so we take the country from the merchant description. A line that gets through every rule unmatched goes on a checking list. Nothing receives a default without someone seeing it.
A file the old system will accept
AJUR takes one thing only, its own file. That file uses a custom delimited format, a set encoding, a block structure and sequential registration numbers. We turn each reconciled transaction into a debit and credit entry in precisely that format. The automation builds and delivers the file. The accountant runs the import and decides what gets posted and when.
- Re-runs are safe. Running again rebuilds the whole month as a new batch, not a delta that might clash with numbers already imported. Older batches stay on record.
- Reporting. Each month a report lists every transaction with its status, its match and its accounting entry. Flagged rows sit apart in a review queue.
Stack
| Layer | Tools |
|---|---|
| Orchestration | Self-hosted n8n |
| Data sources | Exports from Stripe, PayPal, Wise, CoinGate, Kraken and the bank |
| Workspace and settings | Google Drive via n8n service connectors, plus an Excel workbook the accountant owns |
| Business rules | Per-route matching engines, VAT logic, supplier classification in a fixed order, currency conversion |
| Ledger | AJUR, via its own import format |
03
The outcome
| Before | After | |
|---|---|---|
| Month-end close | 3-4 days of accountant time | A single unattended run |
| Invoice processing | Manual | 100% |
| Bank statement lines | Sorted manually | About 95% automatic |
| Journal entries | Keyed in one at a time | One file imported straight into the ledger |
| Payback | Roughly 3 months |
- One monthly run produced 600 invoices and 1,778 accounting lines, left 11 rows for review and raised 0 system errors.
- Every invoice processed, 100%, and roughly 95% of bank statement lines handled without a person.
- 3-4 accountant days saved each month. Payback came in roughly three months.
- Each order can be traced from start to finish: from the order, via the processor and intermediary account, to the bank line and its accounting entry.
- Unclear cases are shown, not guessed. When the data cannot decide, the row is flagged and the reason is written on it.
- The firm now runs the same configuration and exception framework for more than one of its clients.
The risk that gets overlooked
Providers change their export formats. New channels and intermediary accounts show up. If nobody owns the configuration, match rates slide and no one notices. In this setup every rule and every account sits in a workbook under the accountant's control.
Built with
The platforms and tools this engagement runs on.
More case studies
Similar problems, measured the same way.

Accounting practice, Bulgaria · monthly close for a web shop handling 1,000-1,500 orders
Month-End Close Automation for a 1,500-Order Online Store
- for a whole month, reconciled and posted
- < 2 min
- for a whole month, reconciled and posted
- of sale records matched with no manual work
- 98%
- of sale records matched with no manual work

Accounting practice · Bulgaria · 10-15 people, bookkeeping for 100+ client companies
Bank Statements That Reconcile and Post Themselves
- of transactions reconciled and posted automatically
- ~90%
- of transactions reconciled and posted automatically
- statement formats from Bulgarian banks
- 5
- statement formats from Bulgarian banks

Bulgarian accounting firm · 10-15 people · bookkeeping for 100+ client companies
Hands-Free Bank Statement Retrieval
- client companies handled twice a month
- 70+
- client companies handled twice a month
- bank portals driven by RPA
- 3
- bank portals driven by RPA





