When to Structure, When to Listen

Standardisation helps machines, but messiness is often human. This post explores when it’s wiser to build better tools than to force better inputs.

When to Structure, When to Listen

Lessons from Bookkeeping, AI, and the Limits of Order

I recently found myself caught in a quiet paradox. In an effort to streamline my bookkeeping, to make it “machine-ready”, I leaned heavily into structure. I introduced standards, formats, and automation protocols. In theory, this would make everything flow: less error, more speed, greater control.

But in practice, something else happened. The humans got confused.

Invoices became harder to read. The colours and layout that once gave clarity disappeared into abstract codes. I found myself debugging exchange formats instead of focusing on what mattered. A simple act, sending or processing a payment, turned into a complex dance between incompatible assumptions. And all of it, ironically, in the name of efficiency.

So I did something counterintuitive: I stepped back. I returned to the basics. A clear PDF, readable by a person. Only on request would I offer a structured version, like UBL or XML, and only when the receiver was actually equipped to handle it. What emerged from that shift was not just a better process, but a deeper realisation: not everything should be structured by default.

Invoices in the Eurozone: A Practical Guide to SEPA Payments and Digital Processing
Understand SEPA, EPC QR codes, and UBL invoices. A hands-on guide for anyone sending or receiving payments in euros within the Eurozone.

Two Paths: Standardisation vs Interpretation

In many domains — bookkeeping, healthcare, legal documents — there's a natural tension between two approaches:

One is standardisation: use fixed formats, schemas, and identifiers. It’s structured, machine-friendly, and promises automation.

The other is interpretation: embrace the variability of natural documents, and rely on tools like OCR or AI to make sense of them.

Both have value. But they represent different philosophies.

Standardisation assumes the world can be ordered in advance. Interpretation accepts that much of what we work with, from invoices to language itself, is inherently noisy, sometimes even dubious by nature, not because it’s sloppy but because life is complex.

My own invoices were 90% fine with OCR. Sometimes a figure would be misread, and that was annoying. But I’ve seen similar levels of error in structured formats, where a single broken tag in an XML file would derail the entire process. In other words, structure doesn’t eliminate mess, it just hides it behind a stricter contract.

The Tipping Point: Smarter Tools, Not Stricter Inputs

This is where the idea crystallised for me: there is a tipping point where improving the interpreter is more effective than enforcing structure.

Rather than expecting all senders to comply with rigid standards, we can build tools that are robust against variation — tools that don’t collapse at the sight of a missing field or a shifted column.

This isn’t just a technical insight. It’s a philosophical one. It’s the idea that tools should adapt to reality, not just force reality to adapt to tools.

This mirrors a broader development in AI. On one hand, we have symbolic systems: logic, rules, ontologies. On the other, we have neural systems: flexible, pattern-based, probabilistic.

Neurosymbolic AI tries to combine the two: bring structure into neural systems, and context into symbolic reasoning. But the danger is always overreach, trying to make things more formal than they really are. The insight I take from bookkeeping is that a good enough interpretation of a messy input is often more practical than a perfectly structured model.

Rules and Guesses: The Twin Engines Behind Smarter AI
AI isn’t just smart, it’s a duet. One part rigid and logical, the other fluid and generative. Together, they form the neuro-symbolic systems behind real insight.

Apollo and Dionysus: Order and Chaos in Dialogue

This is not new. The Greeks saw it too.

Apollo represents clarity, form, rationality.

Dionysus brings ambiguity, flow, emotion.

We tend to privilege Apollo when building systems. But Dionysus has his place, especially where life resists simplification. A good system doesn't eliminate Dionysus; it listens to him. It allows for his unpredictability. That’s where robustness lives.

Conclusion: Let Structure Serve, Not Dominate

I still believe in standards. But only when they serve the task, not when they overtake it.

Sometimes, the better investment is not in cleaning the world, but in building tools that can see it clearly, even when it’s a bit messy.

If we get the balance right, we won’t have to choose between order and chaos. We’ll build systems that read the world as it is, not just as we wish it to be.