Article

Why I Refused to Generalize a Working Financial System

Receiva began with one operation. The next architecture question is how to support another without making the working system pay for abstractions that do not exist yet.

Engineering Journal
Published 2 min read

The question

Receiva began as an operational layer for GoldCash, a motorcycle-financing operation with a real portfolio and real financial-integrity requirements. Fomentis is the financial source. Receiva adds operational context: portfolio, agenda, contacts, negotiations, payment promises, next actions, history, safety gates and controlled publication.

The next question is not “how do we turn this into a SaaS?” It is: how can Receiva support another operation without breaking what already works for GoldCash?

Verified current state

Receiva is a real operating product in active development and use around the current operation. Its current direction includes FOMENTIS_SYNC, where source data remains traceable, and operational views that make follow-up and financial context easier to review.

UNICAR is the first external client or operation in discovery. Its spreadsheet is product evidence for understanding the operation, not the schema. This record does not claim that UNICAR is running in production.

The architectural decision

The current decision is to keep two concepts distinguishable:

  • FOMENTIS_SYNC: preserve the existing source and its reconciliation boundary.
  • RECEIVA_NATIVE: a possible isolated native financial mode for operations that need it.

The principle is simple: do not generalize GoldCash by force. Client-specific import adapters can be introduced where the evidence requires them, while the working financial source remains protected.

Safety before abstraction

The engineering surface includes golden-master protection, regression control, backups, disaster recovery, auditability, performance work, controlled publication and explicit safety gates. These are not decorative platform features; they protect the integrity of a financial operation.

That is also why unnecessary event sourcing and premature multi-tenancy are not assumed defaults. A future capability can be discovered and isolated without turning today’s working product into an abstraction exercise.

Discovery / future direction

RECEIVA_NATIVE is a discovery direction, not an implemented mode. Adapter boundaries and support for other operations are architectural possibilities under investigation. Multi-tenancy is not claimed as implemented, and Receiva is not represented as a mature SaaS platform.

Retrospective interpretation

The useful question is not whether the architecture can imagine every future customer. It is whether the current customer is forced to pay the complexity cost before those customers exist.

That is the tension: a working financial system should be allowed to evolve, but not at the cost of hiding its source of truth, weakening recovery or making operational behavior harder to audit.

Published by

Juan Gomes

Part of

NorthCore Journal

Published