Syndicated Loan Agency and Participation Software: Why Every Payment Date Starts With a Spreadsheet Reconciliation

The two days before every payment date

A payment date is coming up on a $600 million facility with a term loan, a revolver, a delayed draw tranche and two outstanding letters of credit. The agent's ops team starts two days early. The servicing system holds the facility, but the deal has a leverage-based margin grid that resets on delivery of quarterly financials, a ticking fee on the undrawn delayed draw with a step, and a most favoured nation provision that nobody has needed yet. Those live in a spreadsheet maintained by one person. Three secondary trades settled since the last payment date, two of them with delayed compensation, so the lender of record on those positions changed mid-period and interest has to be split at the trade date rather than paid to the current holder. Somebody rebuilds the allocation table by hand, somebody else checks it, and the notices go out as PDFs attached to emails at 4pm.

Then a lender calls. Their share is off by $1,840. It is off because the trade allocation used a settlement date where the deal terms say trade date. The agent will make them whole, and the compensation claim is small this time. The point is that the process which produced that error produces the same class of error every quarter, and on a larger facility with a larger trade volume the number is not small.

This is not a story about bad operations teams. Agency operations teams are among the most careful people in banking. It is a story about what happens when the system of record models a standard structure and the credit agreement is a negotiated legal document that does not match it. The gap between those two things is filled with spreadsheets, and spreadsheets do not have an audit trail, do not survive the person who built them, and do not tell you when they are wrong.

The credit agreement is bespoke and the servicing system has a fixed model

Loan IQ and ACBS are genuinely the systems of record for agency servicing, and they do the core accounting properly: accruals, drawdowns, repayments, position keeping, general ledger integration. They have to be, given what runs through them. Where they show their limits is deal-specific economics that the product's data model does not have a field for. A pricing grid keyed to a covenant ratio with a delivery-date trigger and a default rate when financials are late. A PIK toggle at the borrower's election with notice conditions. An accordion with conditions precedent. A tranche denominated in a second currency with its own rate basis. Multiple facilities cross-collateralised with a shared waterfall.

Every one of those is expressible in a bespoke system and awkward in a packaged one, and the workaround is always the same: encode what fits, keep the rest in Excel, and rely on an experienced person to remember which is which. Private credit managers acting as agent on their own deals feel this most acutely, because their structures are more varied by design and their operations teams are smaller.

What a custom build does: model the deal terms as data with the same seriousness the credit agreement gives them. Margin grids as effective-dated rules keyed to the ratio and its delivery obligation. Fees as defined calculations with their own accrual basis and payment frequency, including ticking, commitment, letter of credit fronting and utilisation fees, each computed rather than typed. Elections and toggles as events with conditions. Then the system computes what is owed and to whom, and your servicing system remains the book of record while the calculation stops depending on somebody's memory. That is the important architectural point: you are not replacing Loan IQ, you are removing the spreadsheet that sits next to it.

The lender of record moves under you, constantly

Secondary trading is what makes agency operations structurally different from bilateral lending. Positions change hands, sometimes repeatedly, sometimes with settlement lagging trade date by weeks. Delayed compensation exists precisely because settlement takes longer than the market would like, and the LSTA conventions around it are well established, but applying them correctly means the system must know trade date, settlement date, the type of trade, whether it was assignment or participation, and how the specific credit agreement treats interest accrued between those dates.

ClearPar handles the settlement process itself and does that job well, but a settlement platform is not a position-keeping system and it does not compute your allocations. The agent still has to reconcile what settled against what its own records say, and that reconciliation is where the errors that generate compensation claims are born.

What a custom build does: hold positions as a time series rather than a current balance. Any allocation for any date range is derived by asking who held what across that range, which makes a mid-period trade an ordinary case rather than an exception. Trades are captured with trade date, settlement date, type and counterparty, and the interest split follows the agreement's own rule. Pending trades are visible in the allocation preview, so an operations analyst can see before the payment date that three positions will change and what the split will look like either way. Reconciliation against the settlement platform becomes a scheduled exception report rather than a pre-payment scramble.

Rate periods after LIBOR are a calculation, not a lookup

The transition to SOFR and other risk-free rates changed the shape of the work. Term SOFR behaves like a lookup, so it is manageable. Daily simple and daily compounded conventions do not: they accrue across the interest period, they involve lookback and observation shift conventions that vary by agreement, and they require a rate series rather than a single fixed rate at the start of the period. Add credit spread adjustments that differ by tenor and by deal, legacy fallback language, and multicurrency tranches with different rate bases, and interest calculation stops being a formula somebody can check by eye.

What a custom build must include: interest calculation as a first-class, testable engine with the convention modelled per tranche. Lookback days, observation shift, floor application order, day count, business day conventions and the specific calendar all configured per facility rather than assumed. Every accrual must be reproducible from stored inputs, meaning the rate series used is retained, not re-fetched, because a rate provider correction should produce a documented recalculation rather than a silently different answer next time you open the screen. Then borrower and lender notices show the calculation, not just the result, which removes most of the queries the ops team currently answers by email.

Notices are the product, and they go out as email attachments

What a lender actually experiences from an agent is notices: borrowing notices, rate set notices, interest and fee payment notices, amendment requests, waiver solicitations, consent tabulations, financial statement distributions. In most agency shops these are Word templates merged by hand or exported from the servicing system, attached to an email, and sent to a distribution list maintained in Outlook. Then consent responses come back as replies, and someone tallies them in a spreadsheet against commitment amounts to determine whether the required majority has been reached.

That last one deserves attention because it is a legal determination. Whether an amendment has passed depends on the voting threshold defined in the agreement, applied to the commitments of the lenders of record at the relevant time, sometimes excluding affiliates or disqualified institutions. Tallying that in a spreadsheet from email replies is how agents end up in uncomfortable conversations.

What a custom build does: generate notices from the same data that computed the numbers, so a notice can never disagree with the ledger. Distribution goes to a maintained contact model with roles per lender institution, so a personnel change at a lender is one update rather than a search through Outlook groups. Consent solicitations run as structured requests with a portal response, an audit trail per responder, an automatic tally against current commitments with the agreement's own threshold, and a clear view of who has not responded. Lenders get a portal where their positions, notices, historical payments and tax documentation live, which reduces inbound queries substantially and is the feature lenders themselves ask for most.

Fees and waterfalls are where the quiet leakage lives

Agency fees, upfront and amendment fees, letter of credit fronting fees, commitment and ticking fees, and the waterfall that governs how a payment is applied across principal, interest, fees and expenses in a deal that has gone sideways: all of this is deal-specific and much of it is computed manually. In healthy deals the error is usually small and one-directional, meaning the agent forgets to bill something. In stressed deals the waterfall becomes the whole argument, and a manual application of a payment against a contractual waterfall is a place where an agent can create real liability.

What a custom build does: model the waterfall explicitly per credit agreement, apply payments through it deterministically, and produce a payment application statement showing each step. Fee accruals run automatically with their own basis and calendar. Nothing about this is technically exotic. The value is that it is computed the same way every time, by the same rule, with a record.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this category prices as follows. A first release covering deal term modelling including margin grids and fee definitions, time-series position keeping with trade capture, allocation calculation with mid-period trade handling, and a pre-payment-date reconciliation against your servicing system runs $110,000 to $220,000 over 14 to 20 weeks. A full platform adding interest calculation engines for daily compounded conventions, notice generation and distribution, a lender portal, consent solicitation and tabulation, fee automation and waterfall application, plus settlement platform integration, runs $300,000 to $700,000 phased over 9 to 16 months.

Cost drivers specific to agency work: multicurrency, which touches every calculation and every notice. The number of distinct rate conventions across your book, since a portfolio spanning term SOFR, daily compounded SOFR, EURIBOR and legacy fallbacks is four engines rather than one. Whether you agent for third parties or only your own deals, because third-party agency brings client reporting and service level expectations. And integration depth with your servicing system, where read access to positions and accruals is straightforward and writing back is a longer conversation with the vendor.

What holds cost down: starting with allocation and reconciliation only. It is the highest-error, highest-pain area, it requires no write-back to the servicing system, and it can run in parallel with the existing process for a quarter to prove itself before anyone depends on it.

Build versus buy

Buy, and stay bought, for the book of record. Loan IQ and ACBS handle accruals, positions and general ledger integration at a level of correctness that is not worth reproducing, and replacing a working agency servicing system is a programme with a poor risk-adjusted return. If you are agenting fewer than roughly 10 club deals with conventional terms, a disciplined spreadsheet plus a careful ops manager is a legitimate answer and we would tell you so.

Build the surround when the shadow spreadsheet has become load-bearing. The specific signals: your team starts payment date preparation more than a day early, a compensation claim has been paid in the last year for an allocation error, deal terms routinely require workarounds in the servicing system, or your book has grown to where one person's departure would be an operational event. Private credit managers acting as agent on their own paper reach this point quickly, because deal variety is a feature of the strategy and the operations team was sized for a smaller book.

Do not build a settlement platform. ClearPar exists, the market uses it, and reproducing market infrastructure is a category error. Integrate with it.

How to choose a developer for loan agency software

Ask how they would compute an interest allocation when a position traded mid-period with delayed compensation. If positions are not held as a time series in their answer, every mid-period trade will be an exception and you will keep the spreadsheet.

Ask how a daily compounded SOFR accrual is made reproducible. Retaining the rate series used, rather than re-fetching it, is the correct answer, and they should immediately raise what happens when a rate is corrected after the fact.

Ask how consent tabulation determines whether a threshold has been met. The answer needs commitments as of a specified time, the agreement's own threshold, and treatment of affiliates or disqualified lenders. Anyone who treats it as counting replies has not understood that it is a legal determination.

Ask what they have integrated: name the servicing system, the settlement platform, and whether they have worked with FpML messaging. Then settle ownership before kickoff. You should own the repository, the cloud environment and the data. At Digital Heroes the client owns all of it from the first commit, and in a business where the calculation is the service you sell, owning the logic that produces it is not negotiable.