Commercial Mortgage Servicing Software: How Do You Produce the CREFC Investor Reporting Package Without Rebuilding It by Hand Every Month?

Why commercial servicing breaks where residential servicing does not

Residential servicing scales because a million loans share about a dozen shapes. Commercial servicing does not scale, because every loan is a negotiated document and the document is the specification. Two loans on identical office buildings in the same submarket, closed three months apart by the same lender, will define debt service coverage differently, deduct different reserves, use a different lookback period and trigger cash management on different tests. There is no standard product to configure against, because there is no standard product.

So the operation splits in two. The servicing system holds payments, escrows and the general ledger, and it does that well. Everything the deal documents actually require lives in a spreadsheet per loan, maintained by an asset manager who knows the deal. When the portfolio grows from 150 loans to 600, or when that asset manager leaves, the operation discovers that its real system of record was a folder of workbooks with no version history.

Then the calendar arrives. Determination date each month, remittance to the trustee behind it, and the investor reporting package assembled from data that has to be gathered, normalised, tested and validated in a fixed number of days. No amount of goodwill compresses that when the source is a hundred emailed PDFs.

Problem 1: the covenant test is defined in the loan document, not in the software

A debt service coverage ratio sounds like a single formula until you read three loan agreements. One uses net operating income, one uses net cash flow after a replacement reserve at a stated dollar per square foot, one imposes a management fee floor whether or not the borrower pays one. One tests on a trailing twelve month basis, one annualises the most recent quarter, one uses year to date annualised with a seasonality carve out. Debt yield definitions vary the same way. Occupancy tests can be physical, economic, or measured against a named anchor tenant with a going dark clause.

None of that fits a configuration screen with a dropdown for DSCR method. What it fits is a per loan definition object: the numerator components, the deductions with their own rules, the denominator including whether the debt service is actual or a constant, the period basis, the test frequency, the threshold, the cure rights and the consecutive period requirement before a trigger springs.

What a custom build does is treat that definition as first class data captured once at boarding, reviewed against the document by someone who read it, and then executed automatically every reporting period. The output is a computed test with every input visible, so when a borrower disputes a cash trap you can show which line items produced the number rather than sending them a workbook and hoping.

Problem 2: borrower financials arrive as a hundred different documents

The reporting obligation is straightforward on paper. Quarterly operating statements, quarterly rent rolls, annual statements, sometimes audited. What actually arrives is a property manager export in one format, an owner spreadsheet with a bespoke chart of accounts, a scanned PDF, and a rent roll with merged cells and a totals row in the middle. Every one of them has to be mapped into a normalised chart before any comparison is possible, and the normalisation is where judgment lives: what counts as a capital item, whether a management fee was booked, how a tenant reimbursement was classified.

This is the highest value place to apply document extraction in the whole category, and it is not a chatbot. A model reads the rent roll and returns tenants, suites, square footage, lease start and expiry, base rent and reimbursements as structured rows. It reads the operating statement and proposes a mapping to your standard chart, learning each borrower own naming over time. A human analyst reviews and confirms, because the normalisation decision drives the covenant test and eventually the reported net operating income, and no analyst should sign a number they did not see derived.

The gain is not eliminating the analyst. It is moving them from typing to reviewing, which is what makes a quarterly cycle fit inside the quarter. It also produces something the spreadsheet never could: a comparison of this period to the prior period and to underwriting, with variance flags on the line items that moved, which is how a watchlist candidate gets spotted before it becomes a delinquency.

Problem 3: reserves and cash management are a per deal machine

Tenant improvement and leasing commission reserves, replacement reserves, tax and insurance escrows, springing reserves that begin funding when a test fails, and cash management with a lockbox that sweeps on a trigger and releases on a cure. Every draw request has conditions: invoices, lien waivers, a signed lease, an inspection, a maximum per tenant and lender approval inside a stated period.

Servicing systems hold escrow balances. They do not hold the conditions, so draw administration runs on email and a checklist. The failure mode is not usually a wrongly released dollar. It is time: a borrower waiting on a leasing commission draw while a lease sits unsigned, which is a real asset management cost, and a draw file that cannot be reconstructed when the loan later transfers to special servicing.

A custom build models the reserve, its conditions, the required documents and the approval chain, so a draw is a workflow with evidence attached rather than a thread. Trigger events and cure provisions become computed states off the covenant engine, which means a cash sweep starts and stops because a test said so, with a record of when and why.

Problem 4: one whole loan, several trusts

A large loan is rarely one asset. It is split into pari passu notes across several securitisations, sometimes with a subordinate companion piece, sometimes with mezzanine debt above the borrower and an intercreditor agreement governing who does what. The property data is shared. The allocations are not: principal, interest, prepayment consideration, fees and advances all divide according to the deal documents, and each trust needs its own reporting on its own template.

This is the place where spreadsheets do the most damage, because the allocation arithmetic is simple enough that everyone believes the workbook, and complex enough that nobody re derives it. A build models the whole loan once, then models each note with its share and its trust relationship, and computes allocations from the shared cash events. The reporting then generates per trust from a single source of property and loan truth, which also means a corrected rent roll fixes every trust package at once instead of three separately.

Problem 5: the package is a deadline, not a report

The CREFC investor reporting package is a defined set of files, including loan setup and periodic update, property and financial files, the comparative financial status report, the servicer watchlist, delinquent loan status, historical modification and REO reporting, plus operating statement analysis with net operating income adjustments. Master servicers also carry advancing obligations with recoverability determinations, and appraisal reduction events change advancing.

Assembled by hand, this is a multi day exercise repeated monthly, and the risk is not just lateness. Reg AB servicing criteria attestation and the annual attestation regime mean your process itself is examined, and a process whose only control is a careful person is difficult to attest to honestly. A generated package with validation rules run before submission changes the shape of the month.

What STRATEGY, Precision LM and Backshop do well, and where they stop

McCracken STRATEGY is the system of record across most of this market and it earns that position. Payment processing, escrow administration, investor accounting and the general ledger side are exactly what it should be, and no serious operator replaces it as a first move. SS&C Precision LM covers similar ground with different strengths on the loan accounting side. Backshop is genuinely good at origination and asset management workflow, particularly for debt funds and life companies underwriting their own paper.

They stop at the same boundary. None of them holds your per deal covenant definitions as executable data, because those definitions are not a product feature, they are your documents. None of them normalises borrower operating statements from arbitrary formats. None of them allocates a pari passu whole loan across trusts with your intercreditor terms. And the reporting package still gets assembled with meaningful spreadsheet work in between. Every servicer we have talked to in this category runs the same architecture: a strong system of record plus a shadow layer in Excel that carries the deal specific logic. The build replaces the shadow layer, not the system of record.

What this costs and how long it takes

Across the projects Digital Heroes has delivered, a first release covering borrower financial intake with extraction and normalisation, the per loan covenant engine, watchlist rules and package generation runs $120,000 to $250,000 and ships in 14 to 20 weeks. A full platform adding reserve and draw administration, cash management triggers, whole loan and trust allocations, advancing and recoverability tracking, a borrower portal and investor distribution runs $300,000 to $700,000 phased over 9 to 18 months.

What drives cost specifically here: the variety in your loan documents, since a book of similar bank originated loans is far cheaper to model than a conduit book from many originators; the number of trusts and templates you report into; whether you act as master, primary or special servicer, because special servicing adds a whole workflow around transfers, appraisals, modifications and resolution; and the state of your document files, because if covenant definitions have never been abstracted from the loan agreements, someone has to read the documents, and that is a legal review workstream, not a software one.

Build versus buy, and when buying is the right call

Buy or outsource, and we will say so, if you hold a few hundred straightforward whole loans on your own balance sheet with no securitised reporting obligation. A servicing system plus disciplined workbooks plus a competent analyst is genuinely enough, and a build would be an expensive way to organise a manageable problem.

Build when two or more of these are true. Your covenant math lives in a workbook per deal and only one person can explain it. You report into multiple trusts, or you are a master servicer with sub servicers feeding you. Borrower financial normalisation consumes weeks of analyst time every quarter and still runs late. You hold whole loans split across securitisations and allocate them in Excel. Or your process for producing the reporting package cannot survive the attestation regime without a heroic individual, which is a control weakness dressed up as a good employee.

How to choose a developer for commercial servicing software

Ask them to whiteboard the data model before you sign anything. Someone who has done this draws property, then loan, then note, then trust, and immediately asks how a whole loan splits across notes and how the intercreditor terms govern allocation. Someone who draws loans and payments has built consumer lending software.

Ask how they would represent a covenant definition. If the answer is a dropdown of standard calculation methods, they have not read a loan agreement. The right answer is a structured definition per loan with components, deductions, period basis and cure terms, captured at boarding and executable.

Ask what they have integrated and what they have extracted. Reading a rent roll with merged cells is a different problem from reading an operating statement, and both are different from a STRATEGY extract. Ask for the specific format and the accuracy achieved with a human review step.

Ask how the system proves what it reported. Every generated package should be reproducible from stored inputs, with an audit trail of who confirmed which normalisation, because that matters during an attestation or a transfer to special servicing. Then ask who owns the code. At Digital Heroes the client owns the repository and the infrastructure accounts from the first commit.