3 problems we worked on.

Situation

A multi-entity company ran operational reporting and financial consolidation on separate systems. After each close, operational corrections kept arriving: a rebilled invoice, a reclassified cost, a late entry. Finance needed the figures as they were published at close. Operations needed the corrected figures as they are today.

Problem

Both views are legitimate. The published number is the one the group reported and must be able to justify. The corrected number is the one the business now runs on. But the systems only kept the latest state, so every difference between the two had to be rebuilt by hand: what changed, when, by whom, and how far it had propagated through the reporting chain.

What Filiament did

Filiament connected the operational and financial environments through a shared business model. It preserves every state of every record, detects changes made after a close, explains the difference between two states, and traces how a correction propagates from one system to the next.

Outcome

Finance can reproduce a close exactly as it was published, at any date. It can see what changed since, trace each change to its source, and justify each difference. Reconciliation between operational and financial reporting runs on explicit rules instead of manual rebuilds.

Situation

A multi-entity company ran its operations on two legacy ERPs spread across 17 instances, and its accounting on 70 instances of a different system, one per entity. Synchronization between the two had become unreliable: 50 to 60 people, from sales administration to the subsidiaries, raised tickets whenever records disagreed. Some invoices created in the ERP never reached accounting, which in practice meant cash that never got collected.

Problem

Our investigations surfaced three ERP instances sharing one database; 15,000 invoices flagged as new that were existing invoices whose identifiers had changed; foreign-currency invoices propagated as euros; VAT at zero on part of the history; duplicate customers and suppliers created by the old process; and two accounting instances running in parallel for the same entity during a merger. Teams could see that records disagreed, but nobody could say which rule or transformation had produced the difference.

What Filiament did

Filiament connected both environments and encoded the underlying business rules in a shared ontology of about fifteen core entities. Applications no longer reconcile with each other: master sources feed the layer, every transformation is explicit, traceable and replayable, and clean, rule-checked records are written back to the target systems.

Outcome

• Invoices created in the ERPs reliably reach accounting.
• The ticket flow from those 50 to 60 users dries up.
• Anomalies, identifiers, currencies, VAT, duplicates, are detected and traced instead of silently propagated.
• The same layer now secures the migration to the group's next ERP.

Situation

A multi-entity company steered a critical financial process, the forecast of future cash collections up to 6 months out, through 25 macro-driven spreadsheets maintained by IT. Data was copied in by hand from accounting and project tools. When one person had a file open, nobody else could edit it. Each subsidiary had its own conventions, down to inverted columns. One corrupted file could stop the financial steering of the subsidiaries.

Problem

There is no universal key for matching an invoice to a project. One subsidiary matches on the last six digits of a code. Another follows a different logic entirely. Some invoices reference no project at all. As long as those rules lived in spreadsheets and habits, they could not be shared, checked or maintained.

What Filiament did

Filiament connected the underlying sources: four accounting instances, the group's collaboration platform, with the full history of the old spreadsheets taken over in one pass, and a subsidiary's new ERP. It encoded each subsidiary's matching rules explicitly, and routed the invoices no rule could match into a scoped, traced manual process instead of an invisible copy-paste.

Filiament provided the governed business layer underneath the application. The application itself was built downstream of Filiament and calls Filiament data directly through its API.

Outcome

One operational application replaced the spreadsheet infrastructure. Project managers consult and follow their own projects in it, finance steers cash and collections on the same data, and each team works on the scope it owns. The application is fed continuously, nothing is copied by hand, and rules differ by subsidiary while staying explicit and reusable.

The application is one consumer on top of Filiament. A BI tool, a data warehouse or an AI agent would plug into the same layer, through the same API, with the same governance.