Why we built our own ERP at Eximus

There is a point in a company's operations where working across banks, spreadsheets, external portals, email threads, manual reports, and disconnected tools stops feeling "normal" and starts becoming expensive.

Not always expensive in immediate cash. Sometimes the cost appears as rework, fragile reconciliations, slow closes, delayed decisions, and teams spending more energy reconstructing context than running the business.

That is what we started seeing inside Eximus.

So we began building EximusERP — internally, Eximus Finance Ops — as an operating layer to connect critical administrative workflows, leave real traceability behind, and reduce dependence on manual bridges.

The problem was not a lack of software

We already had software.

The bank handled one part. Formal accounting lived in another platform. Executed work lived in Azure DevOps. Supporting evidence showed up in documents and emails. Billing and collections followed a separate logic. And whenever we needed to answer simple questions — what got paid, what got collected, what is still pending invoicing, which collaborator has already been liquidated, which bank movement is already reconciled — we had to open too many tabs and rebuild the story by hand.

That is when it became clear that the bottleneck was not only data capture. It was the absence of our own operating model.

What we chose to build

We did not frame EximusERP as “one more system.” We framed it as a layer that centralizes internal finance operations and turns repetitive work into governable flows.

That meant respecting rules that, in our case, were not optional:

• multi-currency operations with analytical consolidation in COP,
• historical and operational bank imports with idempotency,
• settlements connected to executed work in Azure DevOps,
• billing rules that change by agreement type,
• billing and collections workflows integrated with Siigo,
• reconciliation between bank movements and real operating events,
• and full traceability for runs, incidents, and source data.

This kind of operation often ends up being managed through improvised combinations of Excel, loose scripts, and manual review. We preferred to turn it into an internal product.

Where the operation starts to improve

One of the first gains was not “more automation.” It was being able to read cash with more confidence.

EximusERP already supports historical and operational imports from accounts such as Davivienda and Global66 in COP, USD, and EUR. It works with a multi-currency model while keeping COP as the base currency for analysis. It also distinguishes internal transfers and currency conversions so they are not misread as revenue or expense.

That becomes truly useful when the process can be rerun without fear. The imports were designed to be idempotent: each row is normalized, assigned a deterministic fingerprint, and checked against unique constraints before entering the system.

That may sound like a small technical detail, but it is not. When a process is not idempotent, every retry feels risky. When it is, retrying becomes a normal part of serious operations.

Useful automation is not only execution

Another important step was moving critical processes out of opaque scripts and into a governed execution layer.

EximusERP manages execution types, reusable profiles, requests launched from UI or API, and a consolidated operating trail in sync_runs, with per-sheet detail and incidents by run. That means an import is not recorded only as “something that ran,” but as an operating event with context: which profile was used, which file entered, what happened on each sheet, which warnings appeared, and which errors need review.

That distinction matters more than it seems. In a growing company, automation without evidence only relocates uncertainty. Automation with traceability actually reduces friction.

Payroll, billing, and collections stop living in isolation

In a knowledge-intensive services company, administrative operations are not separate from delivery. That is why one of the most valuable modules is payroll.

EximusERP takes closed Azure DevOps tasks with completed work, matches them with collaborators, and builds settlements with history, status, and line-level traceability. The point is not only to “integrate ADO.” It is to turn technical work into reliable administrative signal.

The same applies to billing. Not every commercial agreement works the same way, so it makes little sense to force all of them into one rule. The system handles rules by agreement type, customer review, email preview, and closeout with invoice-level traceability.

And then the next bottleneck appears: collections and reconciliation. That is another place where we chose to stop treating receivables as a process disconnected from the rest of operations. EximusERP already documents workflows to synchronize invoices, normalize operating states, register notifications, and look for automatic reconciliation against bank movements.

The value is not replacing everything at once

EximusERP is not trying to erase every external system in one move. That would be a poor reading of the problem.

The company already operates on top of banks, Azure DevOps, Siigo, and other services. The value of this layer is connecting them through shared rules, shared traceability, and a much clearer operating view.

If I had to reduce the contribution to one sentence, it would be this: less manual interpretation, more shared criteria.

That translates into:

• a single operating view of movements, invoices, and settlements,
• less dependence on intermediate files and human memory,
• better ability to audit what happened in each process,
• reusable integrations instead of patchwork by module,
• and a much stronger base for automation without losing control.

What we learned by building it

Several lessons extend far beyond this system.

The first is that the real problem is almost never the interface. It is the model. If there is no trustworthy master for third parties, clients, agreements, or movements, any automation will simply amplify errors.

The second is that in sensitive operations, idempotency and traceability matter more than the appearance of speed. What matters is not running fast once. What matters is being able to run, review, correct, and run again without damaging confidence in the process.

The third is that not everything should be automatic, but everything should be visible. Some decisions still require human judgment. The right move is not to hide them, but to design the system so they remain assisted and traceable.

And the fourth is that building internal tools sharpens external judgment too. It forces you to live through real integration, governance, reconciliation, process debt, and operational adoption problems instead of only describing them.

The next useful step

For us, EximusERP is a way to operate with less friction and better context. But it is also practical evidence of how we think about software: not as isolated screens, but as systems that connect decisions, reduce ambiguity, and make operations more governable.

If your company is also living between manual processes, scattered data, and fragile integrations, the issue may not be a lack of discipline. The issue may be the absence of an operating layer actually designed around how your business works.

If you want to go deeper on how we bring order to data and operating criteria, continue with Data Governance & Compliance. And if you are evaluating how to build or reorganize an internal platform, see how we approach Business Software Development.