The accounting mess starts at the payment instrument

A Dutch entrepreneur posted that their American Express transactions wouldn’t auto-import into Moneybird. Every month, manual export, manual CSV import. They built a tool to make it less painful. Then asked: is this just me?

The founder of Moneybird replied in the thread.

The answer was interesting: credit card providers don’t offer the right formats, and ICS had PSD/Ponto access for a while — then quietly removed it, because they’re not legally required to offer it. They’d rather sit on the transaction data than make your bookkeeping easier.

That’s why Moneybird now offers their own cards. If the transaction happens inside their system, it lands in your bookkeeping in real time. No export, no import, no manual step.

I’ve run into this pattern from the other side — building integrations between payment processors and accounting software. The technical connection is usually not the hard part. The hard part is that the payment instrument controls what data is available, when, and in what format.

Mollie makes their transaction data accessible and well-structured. Most bank feeds work cleanly once connected. But the moment you go slightly outside that set — a credit card with a different provider, a payment method that doesn’t support PSD2, a processor that only gives you monthly statements — the automation breaks before it even starts.

Good rule when building an accounting workflow: start by asking who controls the transaction data and what format it comes in. If the answer is “we get a PDF once a month,” that’s not a bookkeeping problem. That’s an upstream problem.

Sometimes the solution is switching payment instruments.

Sometimes it’s building a workaround.

But you can’t automate data you don’t have access to.