"Single source of truth" gets thrown around in every SaaS pitch deck until it's basically meaningless. Omnea, a London based procurement platform, is a decent case study in what the phrase actually requires architecturally, because their core product depends on it working correctly across an entire company's finance stack.
The problem: supplier data lives everywhere except where you need it
Procurement data in most companies is scattered across spreadsheets, email threads, Slack messages, and half a dozen disconnected point solutions. Legal has one view of a vendor contract, finance has another, IT security has a third. None of them reconcile automatically.
That fragmentation isn't just annoying, it creates real risk: duplicate suppliers nobody notices, compliance gaps that surface only during an audit, and spend nobody can actually account for.
Omnea's pitch is that instead of bolting a dashboard on top of that mess, you need a continuously synced layer that pulls from and writes back to the systems finance, legal, and IT already use. That's a meaningfully harder engineering problem than a read only reporting tool.
The two-way sync problem
A one-way data pipeline (pull data in, display it) is comparatively easy. A two-way orchestration layer, where changes in your procurement platform propagate back out to the source systems and vice versa, is a different class of problem entirely.
You're now dealing with conflict resolution, race conditions between systems updating the same record, and the question of which system is authoritative when two updates disagree.
This is the unglamorous infrastructure work that decides whether a "single source of truth" claim is real or marketing. Any team building similar orchestration layers across multiple enterprise systems will recognize the shape of the problem: sync frequency versus API rate limits, partial failure handling when one downstream system is unreachable, and audit logging robust enough that when a discrepancy shows up, you can actually trace where it originated.
Why natural language intake is the easy part
The AI facing feature that gets the press attention is the natural language request intake, someone typing "I need to get this vendor approved" instead of filling out a form. That's the visible layer. It's also, relatively speaking, the easier engineering problem: parse intent, route to the right workflow.
The harder problem sitting underneath it is making sure that once the request is captured, the resulting data update is consistent, reconciled, and doesn't silently create a duplicate supplier record that undermines the entire premise of having one source of truth.
The takeaway
If you're building anything that claims to unify data across systems your users already use elsewhere, the marketing pitch and the actual engineering effort will diverge sharply. The dashboard is the 10% everyone sees.
The two-way sync, conflict resolution, and reconciliation logic underneath it is the 90% that determines whether the product actually works at scale, and it's exactly the kind of infrastructure problem that gets buried in most startup founder stories in favor of the AI feature that made the funding headline.
Top comments (0)