Operators pay the owners.
Someone has to run the split.

When you own mineral rights, operators drill, sell the oil and gas, and owe you a share of the proceeds. For a book of any real size, that simple idea becomes a job: revenue arrives from a dozen operators, each in its own format, and every dollar has to be split across the families and trusts that hold a fractional interest in each well. Income, depletion, and fees get separated. Beneficiaries get statements. Taxes get filed. And when a bank holds the trust, its system needs the numbers in its exact accounting file, plus a yearly fiduciary review. Then it all happens again next cycle — every month or quarter, forever.

No standard coming in.
No mercy going out.

Three structural facts make this work brutal — and no amount of care or effort makes them go away. Here they are in order.

Nine operators.
Nine private languages.

Every operator formats its check detail differently — different columns, different deduction logic, different ways of saying the same thing. There is no industry file standard for what lands in your mailbox. That's not an inconvenience; it's the reason this entire category of work exists.

The bank doesn't
read intent. It reads bytes.

Reading the paper is only half the difficulty. The other half is harder: a bank trust system doesn't accept a spreadsheet and doesn't interpret what you meant. It loads a file in its exact layout — account structures, identifiers, line order, to the byte — or it rejects the whole thing. In this work, “close” doesn't exist. One mis-read decimal pays the wrong family every cycle until someone notices, and one malformed line bounces a file the day it's due.

A structured database is what
makes translation possible.

A CDEX feed gives you revenue data. A spreadsheet holds numbers. Neither holds the relationships that make a trust distribution work: which well connects to which owner, which owner maps to which trust account, what decimal interest applies to ten digits, what fee rate and depletion rate governs each account. Without those relationships held explicitly, you cannot compute a distribution — you can only type one by hand and hope the math is right.

The database holds every relationship. Wells link to owners. Owners link to accounts. Accounts carry fee schedules and depletion rates. Division orders are enforced to ten decimal digits. When revenue arrives from an operator, the database knows exactly how to split it — across every owner, every account, every trust — without a human touching a number. That is what the translator reads. That is why the bank file is byte-perfect. The precision lives in the data, not in the person formatting the spreadsheet.

Translators are engineered
artifacts, not scripts.

A bank trust file translator is not a CSV export. It is a deterministic program that reads structured data and writes it into the bank's exact format — field by field, code by code, total by total. The spec determines where every byte goes. The translator enforces it. Same input, same output, every time. No probability. No approximation. The kind of thing that, once it is built and validated, you do not argue with — you verify it works and you use it.

Building a translator for a single bank takes weeks of engineering: reading the spec, mapping field positions, handling transaction code sequences, implementing reconciliation checks, and validating against the bank's own sample files. We have done this work. A top-15 US bank trust custodian's translator is live in production, producing files that match the bank's spec byte for byte. Every new bank is one new translator. The database and the engine stay proven.

Building a translator for a single bank takes weeks of engineering: reading the spec, mapping field positions, handling transaction code sequences, implementing reconciliation checks, and validating against the bank's own sample files. We have done this work. A top-15 US bank trust custodian's translator is live in production, proven across 10 generation runs on real data, and producing files that match the bank's spec byte for byte. Every new bank is one new translator. The database and the engine stay proven.

One machine. Built once.
Proven to the penny.

Here is the third option, and the whole payoff in one sentence: the reading, the splitting, the proving, and the bank's file were built once, as machinery, against real paper — so the cycle that used to take a person days now takes minutes, leaves a record an examiner accepts, and costs a fraction of any of the above. Read the diagram left to right: chaos in, proof out. The only human moment in it is yours — the approval in the middle.

We wrap around
whatever you already use.

CDEX is table stakes — everyone can get data in. The bank file is the hard part. Select your platform and see how the integration works.

┌─ Centripetal: first mile ────────────────────┐
│ Automated ingestion → reading → normalization │
│ Structured database (your tenant, your data)  │
└───────────────────────┬──────────────────────┘
                        ↕ data flows both ways
┌─ MineralSoft (unchanged) ────────────────────┐
│ Enverus · Accounting · Reporting · Analytics  │
└───────────────────────┬──────────────────────┘
                        ↓ structured data
┌─ Centripetal: last mile ─────────────────────┐
│ Bank file translator → byte-perfect → sealed  │
│ Reg 9 narrative → year-end → audit trail      │
└───────────────────────┬──────────────────────┘
                        ↓ file loads clean
┌─ Custodian bank ─────────────────────────────┐
│ Top-15 US bank · Frost · BOK · any bank       │
└──────────────────────────────────────────────┘

The questions a careful
buyer should ask.