
1account
Multi-currency invoicing for freelancers
I freelance with clients in different countries, and the same thing broke every month: I'd quote in one currency, get paid in another, owe tax in a third, and then sit in front of a spreadsheet with no real idea what I'd actually earned after FX and taxes.
Every invoicing tool I tried assumed you bill in one currency. So I built 1account around the messy cross-border case instead.
What it does:
👉 Invoices in 35+ currencies, professional PDFs
👉 Get paid via Stripe, bank transfer, or crypto (BTC/ETH/USDT via NOWPayments)
👉One dashboard that converts everything to your base currency, estimates a tax reserve, and shows what is actually safe to spend - not just a pile of "paid" invoices in mixed currencies
Where I'm at: just launched, $0 MRR, no paying users yet. I'm a solo dev based in Thailand billing clients worldwide, which is exactly who this is for. Boring stack on purpose so I can maintain it alone: FastAPI + HTMX, server-rendered Jinja, Postgres, WeasyPrint for PDFs, one Hetzner VPS.
Honest gaps: no recurring invoices yet, no bank import, support is just me.
See a real invoice without signing up: https://1account.com/invoices/public/w71goZNuzlsmJ01dqAARQqRicKZYDc9JwqOIwRosU-k
Screenshots (dashboard, creation flow, crypto payment): https://postimg.cc/gallery/vGfR18R
Free to try, magic-link signup, no card: https://1account.com/?ref=ih
The thing I most want feedback on: is "safe to spend after a tax reserve" a real pain worth anchoring the product on, or is the multi-currency invoicing the stronger hook? Still figuring out which one pulls harder.
About
I feel the need for simple invoicing & income tracking for freelancers/consultants billing clients across borders. Create professional PDF invoices in 35+ currencies, get paid via Stripe, bank transfer or crypto in a min

4 Comments
Quick public-surface check since this is invoices/payments: core headers are stronger than most early launches. HSTS, CSP, frame protection, nosniff, Referrer-Policy, and Permissions-Policy are all present.
The thing I'd tighten before pushing public invoice links harder is CSP: both the homepage and public invoice allow 'unsafe-inline' and 'unsafe-eval' in script-src, and /.well-known/security.txt is 404. For a product asking freelancers to trust invoice links plus Stripe/crypto payment paths, I'd make that trust surface feel as deliberate as the positioning.
Thanks, I really appreciate the feedback 🙏 fixing it as we speak
I'd be careful with one thing.
The question isn't necessarily which hook pulls harder.
The harder decision may be which problem people are actually willing to change their existing workflow for.
Those can look aligned early on while leading to very different signals.
I wouldn't make that call casually in a thread.
Operator take on your actual question: "safe to spend" is the stronger anchor, and here's why. Multi-currency invoicing is a feature, several tools claim it. "What's my real position after FX and tax" is a cash-flow problem, and cash-flow problems are what people pay to stop losing sleep over. The invoicing is how you capture the data; the reserve view is the job.
One thing to get right or it undermines the whole pitch: FX timing. Someone invoices in EUR on the 1st, gets paid on the 25th, and the rate moved 3%. If your dashboard converts at payment-date spot, the "earned" number silently drifts from what they quoted, and they trust it less, not more. Decide explicitly whether you book at invoice date, payment date, or a blended rate, and show which on the line item. Treasury teams call this FX gain/loss; a solo freelancer just calls it "why doesn't this number match." Nail that and "safe to spend" becomes credible.