Trust Accounting and Fiduciary Administration Software: Can Your System Still Produce a Court Accounting Nobody Can Argue With?

Why trust accounting is not accounting

A trust officer is preparing an annual accounting for a family that has been with the institution since 1974. The income beneficiary is the surviving spouse. The remainder beneficiaries are three children, one of whom now has counsel. The question on the table is whether a large capital gain distribution from a mutual fund the trust held was correctly allocated to principal, and whether the trustee fee taken against it was appropriate. Answering this means reconstructing allocations across decades, through amendments, a change of situs, two custodian conversions and a period when statements were produced by a system that no longer exists.

That is the shape of the problem. Every other financial system is concerned with what is true now. A fiduciary system is concerned with what was true then, who decided it, on what authority, and whether it can be defended to a court. Fiduciary liability is personal, records span generations, and the accounting model itself is unlike anything in corporate finance.

This is why replacement projects in trust are rare, large and slow. It is also why the systems being replaced are frequently 30 years old.

The dual ledger that no general ledger models

Principal and income accounting is the core. Receipts and disbursements are allocated between two separate interests: the income beneficiary who receives income during their lifetime, and the remainder beneficiaries who receive principal afterwards. Interest and dividends are typically income. Capital gains are typically principal. Depreciation reserves, trustee fees, and the cost of major repairs split according to rules that follow state law and the trust document, and the Uniform Principal and Income Act and its successor the Uniform Fiduciary Income and Principal Act set the framework in most states, with local variations and a unitrust election available in many.

The subtlety is that the trust document overrides the statute in most respects, and every trust document is different. A system that hard codes an allocation rule set is wrong for a meaningful share of your book. A system that allows a manual override without recording the authority for it is worse, because the override is exactly the entry a plaintiff's attorney will ask about.

What a build has to do is model allocation as a rule per account, sourced from a specific clause, versioned, with every allocation entry carrying the rule that produced it and the person who approved any deviation. Not a checkbox. A citation.

What FIS Global Plus, SEI Trust 3000, InnoTrust and Cheetah actually do

These platforms are real and they encode decades of fiduciary accounting correctness. Trust 3000 and Global Plus run large bank trust departments and they know the principal and income model properly, which is more than can be said for any general purpose accounting package. InnoTrust and Accutech Cheetah serve independent trust companies well and cost far less than a build.

Where firms hit the wall is not the accounting engine, it is everything around it. Discretionary distribution workflow, where a request moves through a committee with documented consideration of the standard in the document, the beneficiary's other resources, and the trustee's reasoning, is typically handled in email and a Word memo. Annual administrative reviews, where every account must be assessed against its terms, its investment policy and its beneficiary circumstances, sit in a spreadsheet with a due date column. Court accounting formats vary by jurisdiction and are often produced by exporting to Excel and reformatting by hand. Beneficiary communication is paper. Document storage is a separate system with no link to the account events it evidences.

The result is that the platform holds the ledger and the institution holds the risk, and the evidence of prudent administration lives in a shared drive.

Problem one: discretion has to be evidenced, not remembered

A discretionary distribution is the highest liability event in trust administration. The trustee exercised judgement. Years later, a beneficiary asks why the trustee approved a distribution for one sibling and declined another. The defence is documentation created at the time: the request, the standard applied from the trust instrument, the information the committee considered, the discussion, the decision and the dissent if any.

A build should make the distribution request a structured object that cannot be approved without the required fields, routes to the correct committee based on amount and account type, records each member's position, and stores the resulting memo linked immutably to the ledger entry that moved the money. Institutions that do this find the committee meeting itself gets shorter, because the preparation is already structured.

Problem two: the fee calculation is more contested than anyone expects

Trustee fees are typically taken on market value against a published schedule, with tiers, minimums, and sometimes separate charges for principal distributions, real estate, closely held business interests or specialty assets. The valuation date convention matters. Whether the fee is charged against income or principal, or split, follows the document and the statute. Firms with a fee schedule that changed in 2011 are still administering accounts under the old one.

Nearly every institution we have looked at has fee exceptions tracked outside the system, which means the fee actually charged and the fee the system would compute disagree for a meaningful share of accounts, and nobody can produce a clean reconciliation. Building the schedule as versioned, effective dated data with a documented exception per account solves an audit finding that tends to recur.

Problem three: the records have to survive longer than the technology

A trust can run for a century. Your system will not. That is not a reason to avoid building, it is a design constraint. The data model has to be documented, exportable in a readable form, and free of logic buried in proprietary formats. Any build in this category should be able to answer, in plain terms, how the institution reads this data in 30 years if the vendor and the platform are both gone.

Practically this means an append only event store with human readable exports, statements retained as generated artefacts rather than regenerated on demand from current logic, and a documented schema. This is also how you satisfy an examiner asking about record retention.

What a first release should include

• A dual ledger with principal and income tracked separately at the account level, with allocation rules sourced per account from the governing instrument and versioned.
• Asset handling for the things trusts actually hold: marketable securities, real property, closely held interests, notes receivable, mineral rights and tangible personal property, each with its own valuation cadence.
• Fee schedules as effective dated data with tiers, minimums, specialty asset charges and documented per account exceptions.
• Discretionary distribution workflow with structured requests, committee routing, recorded deliberation and immutable linkage to the resulting entry.
• Statement and accounting generation retained as artefacts, reproducible exactly as issued.
• Annual administrative review tracking with evidence attached, not a due date spreadsheet.
• An append only history that supports reconstructing any account position as at any past date.

Cost, timeline and the drivers

A first release with the dual ledger, fee engine, distribution workflow and statements runs $150,000 to $350,000 across 20 to 28 weeks. This category runs longer than most because the discovery is heavier: the allocation and fee rules have to be extracted from documents and from senior officers before anything can be built correctly. A full platform with court accounting formats, reviews, tax support, beneficiary portal and remainder interest modelling runs $400,000 to $1,200,000 over 12 to 24 months.

What increases cost: the number of jurisdictions you administer in, since court accounting formats and principal and income statutes vary by state. Specialty assets, particularly real property and closely held business interests, which each need valuation, expense and income handling. Migration from a legacy platform, which in trust is uniquely painful because historical allocations and cost basis going back decades must come across intact and reconcile. Court supervised accounts, which have formal filing requirements. And the volume of trust documents that must be read to configure account level rules, which is genuine work by people who understand what they are reading.

What holds it down: starting with revocable and simple irrevocable accounts on marketable securities, and leaving specialty assets and court supervised accounts to a later phase.

When to license instead of build

License if you administer a few hundred accounts, mostly revocable, mostly in marketable securities, in one or two states. Accutech Cheetah and InnoTrust are built for exactly that and the economics are not close.

Build when two or more of these are true. You administer across multiple states with different principal and income statutes and court formats. A material share of your book holds real property, closely held interests or other specialty assets your platform handles with workarounds. Your discretionary distribution evidence lives in email and Word. Your fee exceptions are tracked outside the system and cannot be reconciled. You have been through an examination or a beneficiary dispute where producing the historical record took weeks. Or your platform is old enough that the vendor's roadmap is maintenance only and you are planning around a sunset.

How to choose a developer

Ask them to explain principal and income allocation before anything else. If they treat it as two ledger codes rather than two competing beneficial interests with a statutory and document driven allocation rule, stop. This is the one concept the entire category rests on and it does not exist anywhere else in software.

Ask how they store a statement. The right answer is that the issued artefact is retained, not regenerated, because a regenerated statement reflects today's logic and today's data and is therefore not evidence of what was sent.

Ask how an account position as at a date 12 years ago is reconstructed. If the design updates rows in place, the system cannot answer a beneficiary dispute and should not be built.

Ask what they have migrated. Bringing decades of allocations and cost basis off Trust 3000 or Global Plus with a reconciliation that ties is a specific skill, and the honest answer involves parallel running and a tie out, not a weekend conversion.

Settle ownership before kickoff: the repository, the infrastructure accounts and the right to hire anyone else. At Digital Heroes the client owns the code from the first commit. In a business where you may need to read these records in 2060, owning the code and the schema is not a negotiating point, it is a fiduciary consideration.