Short answer: create one billing identity, point every vendor at it, forward everything that arrives into one accounting inbox with a rule, keep a short list of the vendors that never email you, and reconcile once a month against the card statement. The whole system is four rules and a folder, and it takes about an hour to set up.
This is the least interesting problem in software and it eats an entire day every quarter if you ignore it. It also gets worse in exactly the way AI-coded projects get worse: fast, quietly and by accumulation.
What a bookkeeper actually wants
Useful to know before you automate anything, because most of what lands in your inbox is not what they need.
- A tax invoice, not a card receipt. A receipt says money moved. An invoice names the supplier, its tax registration number, the date, the description, the net amount, the tax and the total. In most jurisdictions only the second one supports a tax deduction or a VAT reclaim.
- The amount in the currency you were charged in, plus what your bank actually took, when those differ.
- Something that matches a line on the bank or card statement. Merchant names often do not match the product name, which is why reconciliation is the step people skip and then regret.
- One file per charge, named so the date and supplier are visible without opening it.
Ask your accountant whether they want PDFs in a folder, forwarding to a dedicated inbox address, or a receipt capture tool. Most bookkeeping systems, Xero, QuickBooks and FreeAgent among them, have some form of inbox address that turns a forwarded email into a draft bill. Pick their preference and build the rest of the workflow around it.
Step one: one billing identity
Every vendor account uses the same billing email address, ideally something like billing@yourcompany.com rather than a personal address, and every vendor has the same company name, address and tax number in its billing settings. This one change fixes more than it sounds: it makes receipts filterable by recipient, it survives you changing personal email, and it means the invoices are addressed to the entity that is claiming the expense, which matters more than people expect at audit time.
Do the same for the payment method. One card, used only for project spending. If your bank supports virtual cards, one per project is even better, because it turns attribution into a statement filter.
Step two: rules that file everything automatically
In whichever mail system receives that billing address, create a filter for each vendor. Match on the sender domain, not the subject line, because subject lines change and senders rarely do. For each match: apply a label such as expenses/2026, mark it read so it does not become inbox noise, and forward it to your accounting inbox address.
Two details save grief. First, add a catch-all rule matching common billing words in the subject, so a new vendor is caught before you have written its rule. Second, do not delete the originals. Forwarding can silently fail, and the label is your backup copy.
Step three: the vendors that never email you
Some providers only charge the card and leave the invoice in the console, or email a one line receipt while the proper invoice sits behind a download link. Usage-metered services are the worst for this. You will not fix it with a rule, so keep a short list in the same repository as the project:
# ACCOUNTING.md
| Vendor | Invoice arrives | Where |
| ----------- | -------------------- | ---------------- |
| Hosting | email, 1st | auto-forwarded |
| Database | email, renewal date | auto-forwarded |
| Model API | no email | console download |
| Object store| no email | console download |Then one calendar reminder on the same day each month to download the two or three that do not arrive by themselves. Five minutes, not a day.
Step four: a naming convention
Name every file YYYY-MM_vendor_amount-currency.pdf, for example 2026-08_supabase_25-00-usd.pdf. Sorting the folder then sorts by month automatically, duplicates become obvious, and anyone can find a specific charge without opening anything. If you use a receipt capture tool that does OCR, the naming still matters for the ones it fails on, and it will fail on some.
Currency, tax and the two numbers that never match
Most developer services bill in US dollars. If your books are in another currency, every invoice arrives with one number and your bank statement shows a different one, because the bank applied its own rate and a conversion fee. Your accounting system needs both: the invoice amount in the original currency and the amount that actually left the account. Nearly every bookkeeping tool handles this if you give it the invoice in its original currency and let it match the bank feed, so do not helpfully convert the numbers yourself.
Tax treatment is the other recurring trap. Whether a foreign supplier charges you tax depends on where you are, whether you gave them a valid tax registration number, and what they are selling. Put your tax number into every vendor's billing settings on day one. Doing it later usually means the earlier invoices cannot be reissued, and those are the ones your accountant will ask about. If you are not registered, that is fine, but be consistent, because a folder where half the invoices show tax and half do not is what turns a twenty minute reconcile into an afternoon.
Step five: the monthly reconcile
Once a month, open the card statement and tick off every line against the folder. You are looking for three things: charges with no invoice, invoices with no charge, and merchants you do not recognise. The third is where you find the paid tier you enabled for one afternoon in April and have been paying for since.
Set aside twenty minutes. If it takes longer than that, the number of suppliers is the problem, not the process.
The real automation is fewer suppliers
Every step above scales linearly with vendor count. Nine vendors is nine rules, nine sets of billing details to keep current, nine renewal dates and nine lines to reconcile. The only change that makes the work sublinear is reducing the number of commercial relationships.
That is part of why Squiid is built the way it is. Usage across every connected service draws down one prepaid credit balance at the provider's list price, subscription plans pass through at the provider's own price with no fee added, and at the end of the month you get one PDF invoice covering everything, emailed to your billing address and forwardable straight to a bookkeeper. One supplier, one rule, one line on the statement, one document that already shows the split by service.
Whether or not you use it, build the workflow. The half hour you spend on filters this week is the day you do not spend reconstructing a year of card charges next January.