Current state
Receiva is used daily by three people in GoldCash, a family credit operation. I built it and I also work inside that operation. Formal production certification is in progress.
Fomentis remains the financial source of truth. Receiva imports its exports (XLSX/CSV) and adds what the operation needed around them: a reconciled portfolio position, aging ranges, and collection follow-up — contacts, negotiations, payment promises, notices, legal cases and next actions. It does not write back to Fomentis, and it is not a replacement for it.
The source position analyzed for the first version covered about 2,000 titles.
The problem
The data already existed. A view of it that the operation could trust did not. Periodic exports arrive from sources of different kinds — including evidence reconstructed by hand — and turning them into "what exists, what is overdue and who needs attention today" was manual work that was hard to check.
Decisions
- A layer, not a replacement. The financial system stays authoritative; Receiva reads its exports and never modifies it. See ADR-0001.
- Imported data cannot be edited. Accepted source rows are protected against updates and deletes at the database level. Receiva's own operational state lives in separate tables, linked through namespaced source identities rather than foreign keys to imported rows.
- Every number keeps its origin. Figures stay connected to their source file, period, row and import batch.
- Reads follow a published position, not the latest upload. A new import only becomes the current view when a coherent, reconciled position is published.
- Different sources stay different. Official exports and manually reconstructed evidence are parsed and reconciled on separate paths instead of being added together.
- Collection state that does not drift. A pending payment promise past its date is shown as broken when it is read, not by a scheduled job. Publishing new overdue exposure automatically reopens a client that had been marked as resolved.
- Performance through less work. Stored source files and unused columns are no longer fetched on portfolio reads, and a query that ran three times on the portfolio page now runs once (four database round trips became two), with equivalence tests. Timing results will be published only after a reproducible benchmark.
Known limits
- Access is shared: the three people who use Receiva sign in with the same administrator credential. State changes are recorded with before and after values, but they are not attributed to individual people. Individual identity is planned.
- There is no role-based access control. The executive and operational views are different screens, not different permissions.
- Collection work is ordered by explicit operational tiers, not by a scoring model.
- The daily closing is registered manually. Opening a WhatsApp conversation from the interface is not logged automatically; contacts are recorded explicitly.
- No productivity or financial outcome is claimed; none has been formally measured.
Discovery, not capability
UNICAR is the first external operation in discovery. A separate native mode (RECEIVA_NATIVE) and per-operation adapters are architecture work, not implemented capabilities. Generalizing the system comes after evidence, not before it — see Why I Refused to Generalize a Working Financial System.
The public Receiva page uses fictional data only.