Automate loan calculations, journal entries, and billing integrations in NetSuite. NetLoan streamlines loan accounting for efficiency.
Debt accounting is one of those areas where the volume of transactions is low, the value is high, and the calculation is more involved than it first appears. A business with four loans processes perhaps a dozen entries a month, which is why it almost always ends up in a spreadsheet.
That works while the arrangements are simple. It becomes harder when facilities are drawn in tranches, when rates are variable, when borrowing costs have to be amortised over the term rather than expensed, when a facility is refinanced or modified, and when covenants have to be calculated and reported to a lender on a schedule.
This article covers what loan accounting actually requires, where manual approaches strain, and what a purpose built application inside NetSuite changes.
The mechanics are more than recording a payment and splitting it between interest and principal.
Each facility needs an amortisation schedule derived from its terms, covering the drawdown, the repayment profile, the interest basis and the term. That schedule drives the entries for every subsequent period.
Interest has to be recognised on an accruals basis rather than when paid, which means a period end accrual wherever the payment date does not align with the period end.
Borrowing costs, meaning establishment fees, legal costs and similar amounts directly attributable to obtaining the facility, generally cannot simply be expensed. They are capitalised against the liability and amortised across the term using the effective interest method, which produces a different charge each period.
And the liability has to be split between current and non current at each reporting date, which changes as the facility runs down and is a classification most spreadsheets handle by manual adjustment.
This is the specific area where manual approaches most often go wrong, because the arithmetic is genuinely non trivial.
Under the effective interest method, the carrying amount of the liability includes the unamortised borrowing costs, and the interest charge each period is the carrying amount multiplied by the effective rate rather than the contractual rate applied to the principal.
That produces an interest expense that differs from the cash interest paid, with the difference amortising the establishment costs across the term. The pattern is not straight line, which is what catches people out.
Businesses that expense borrowing costs upfront and charge contractual interest thereafter have a simpler model that does not reflect the standard. Businesses that attempt the effective interest method in a spreadsheet frequently build it correctly and then find it does not survive the first modification.
The consequence is a misstatement that is small in any single period and cumulative across a facility's life, and it is exactly the sort of thing an auditor tests.
Fixed rate facilities produce a schedule that holds. Variable rate facilities do not.
Each rate change alters the interest for subsequent periods, and depending on the structure it may alter the repayment amount, the term, or both.
In a spreadsheet this means rebuilding or extending the schedule each time the rate moves, and doing so in a way that preserves the history correctly rather than restating periods that have already been reported.
Where rates move frequently, the model accumulates edits, and edits are where spreadsheet drift originates. A formula that does not extend, a hardcoded figure inserted to make something reconcile, a reference pointing at the wrong row.
The result is a schedule that produces numbers nobody would query, because interest expense is not a figure anybody examines closely unless something else has already gone wrong.
The hardest area, and the one where the accounting treatment depends on judgement before the arithmetic even starts.
When a facility is renegotiated, the first question is whether the change is substantial enough to be treated as extinguishing the old liability and recognising a new one, or whether it is a modification of the existing arrangement.
That distinction changes the accounting materially. Extinguishment produces a gain or loss and a fresh effective rate. Modification adjusts the carrying amount with the difference recognised through profit or loss, and the original effective rate continues.
Getting it wrong misstates both the liability and the current period result.
These events are individually infrequent, which is precisely why they are handled inconsistently. A finance team encounters a refinancing every few years, which is not often enough to build fluency and often enough to matter.
Netgain's NetLoan is one of the applications built to run inside NetSuite rather than alongside it, and the architecture matters as much as the calculation.
Because it sits on the platform, facility data lives in the same database as everything else. The entries it produces post directly rather than being prepared, exported and journalled. There is no integration to maintain and no reconciliation between a debt schedule and the ledger.
Practically, the schedules are maintained by the application rather than by a person, the period entries post as part of the close rather than as a manual step, and the disclosure information is available as reporting.
Rate changes and modifications are handled as defined events with the appropriate recalculation, rather than as edits to a model.
What it does not remove is judgement. Whether a renegotiation is a modification or an extinguishment remains an accounting decision, and the classification of costs as directly attributable remains a matter for the preparer.
A related requirement that frequently sits in a different spreadsheet again.
Facilities typically carry covenants, meaning gearing ratios, interest cover, minimum earnings or working capital tests, calculated on a defined basis and reported to the lender at agreed intervals.
The difficulties are that the calculation basis is contractual rather than standard, so it may differ from the equivalent statutory measure, and that a breach has consequences ranging from a waiver request to a reclassification of the entire facility as current.
Where covenants are tracked in a spreadsheet updated after the close, the business finds out about a breach late. Where they are calculated from the ledger, the position can be monitored during the period rather than confirmed after it.
That difference matters, because a covenant approaching a limit is a manageable situation with notice and an urgent one without.
For groups, loans between entities add a further layer that manual approaches handle poorly.
Each side of an intercompany loan has to be recorded in the respective entity, the interest has to be recognised as income in one and expense in the other, and both have to eliminate on consolidation.
Where the entities operate in different currencies, translation differences arise and have to be handled correctly, which is an area where manual approaches frequently produce a consolidation that does not balance.
And where the loan terms are informal, which is common in groups, the transfer pricing position may need attention as well.
Handling both sides within the same system, with the elimination happening as part of consolidation, removes a category of period end investigation that otherwise recurs.
Loan accounting contributes to the month end close in a way that is small in volume and reliable as a dependency.
In a manual arrangement, somebody updates the schedule, calculates the interest accrual and the borrowing cost amortisation, prepares the journal, posts it and reconciles the liability to the schedule. That is a step with a person attached.
Where the application posts the entries, the step disappears. The interest, the accrual and the amortisation post with the right accounts and dimensions, and the reconciliation between schedule and ledger is unnecessary because they are the same records.
For a business compressing its close, removing dependencies with people attached is worth more than the hours suggest. Our piece on mastering the financial period close covers where this sits among the other improvements available.
Borrowings are a standard audit area and the testing is more involved than the transaction volume suggests.
Auditors will confirm balances with lenders, test the interest calculation, examine the effective interest treatment of borrowing costs, check the current and non current split, and assess covenant compliance and its disclosure implications.
Where the schedules are system maintained and reconcile to the ledger by construction, that testing is straightforward.
Where they are spreadsheets, the auditor is testing a model as well as the numbers, which generates more questions. Any hardcoded value found in the process expands the scope further.
The covenant position deserves particular attention, since a breach at the reporting date can require the whole facility to be classified as current, which changes the balance sheet materially and is the sort of finding nobody wants late in an audit.
Being honest about the threshold matters, because this is a narrower requirement than lease accounting or fixed assets.
Where you have one or two straightforward fixed rate facilities with no borrowing costs to amortise and no covenants, a spreadsheet maintained by somebody competent is entirely adequate.
The case strengthens with the number of facilities, with variable rates, with material borrowing costs requiring effective interest treatment, with covenant obligations, and with intercompany lending across a group.
It strengthens further where the business refinances regularly, since modifications are where manual approaches most often go wrong.
And it strengthens where the current model is understood by only one person, which is the recurring risk across all of these specialist areas.
The discipline that applies to any third party application applies here too.
NetSuite includes capability for recording liabilities, scheduling amortisation and producing the associated entries, and for businesses with simple debt arrangements that may be sufficient once configured.
The honest assessment is where the standard capability stops relative to your requirements, particularly around effective interest treatment, variable rate recalculation and modification accounting.
Establishing that before committing is a short exercise. Businesses occasionally license a specialist application to solve a gap that was a configuration exercise, and the reverse mistake, of forcing a genuinely complex requirement into standard functionality, is equally costly.
Our piece on advanced NetSuite modules to consider after go live covers how to make that judgement generally.
Adopting a loan application is a small project and the work concentrates in setting up the facilities accurately.
Each facility has to be abstracted from the agreement itself rather than from a summary. Drawdown dates and amounts, repayment profile, interest basis and rate mechanics, term, and any borrowing costs with their classification.
The opening position has to be established and reconciled, meaning the current carrying amount including unamortised borrowing costs, so the schedule continues from where the existing records leave off.
The accounting mapping has to be set so interest, amortisation and repayments post to the correct accounts and dimensions.
And covenants, where they apply, have to be defined with their contractual calculation basis, which frequently requires reading the agreement carefully rather than assuming a standard definition.
The modification question is the most diagnostic, because it is the area where spreadsheets fail most reliably and where applications differ most in depth.
Loan accounting sits alongside lease accounting, fixed assets and close management in the ecosystem of applications built natively on NetSuite, and the argument is the same in each case.
Where a specialist requirement sits outside the ERP, you carry a schedule maintained separately, a reconciliation, a manual journal and a second place where the numbers live. Where it sits inside, none of those exist.
The common characteristic of all four areas is that they involve calculations performed repeatedly across long horizons, with occasional events that change the basis. That is precisely the profile that spreadsheets handle well initially and poorly over time.
Our pieces on lease accounting and fixed asset management cover the same reasoning applied to those areas.
If your debt schedules currently live in a spreadsheet, the useful questions are whether the effective interest treatment is correct, whether the model would survive the next rate change or refinancing, and whether anybody other than its author could demonstrate that it is right.
A short review of the facilities, the current model and the effort it consumes each period will usually make the decision straightforward.
Our guidance for chief financial officers covers what the finance function needs from its systems more broadly, and managed services covers the ongoing capability to run specialist applications properly.
If you would like a view on whether your debt arrangements warrant a purpose built solution, get in touch.
