How to Choose Lending Software in New Zealand

Lending software manages loan records and servicing, including schedules, transactions, balances and arrears. Origination, workflows, disclosures, deposits and investment accounts may also be available, depending on the product, modules and configuration.

 

Choosing lending software starts with how your business lends and what must be demonstrated afterwards. A feature list does not show whether a system handles your calculations, exceptions, records or month-end process correctly, so the selection work is about defining those requirements and testing them.

Exodesk is an Authorised Reseller of Intersoft Systems’ finPOWER Connect. This guide covers selection. Our finPOWER Connect page explains the product itself and our implementation and support offer.

The sections below cover what lending software includes, when current tools need a closer look, how to test a lending model, what to check for compliance records and accounting connections, how to plan a migration and how to compare the full cost.

What does lending software cover?

Lending software, also called loan management software, holds the record of each loan and the servicing that follows: the schedule, the transactions applied to it, the balance and any arrears. Around that core, products differ in what they include as standard and what is an optional module.

  • Loan servicing. Schedules, repayments, interest and fee application, allocation, arrears and settlement.
  • Origination. Application capture, assessment workflows and the conversion of an approved application into a live account.
  • Deposits and investments. Account types for lenders that also take deposits or manage investor funds.
  • Documents and workflows. Disclosure documents, prompts and recorded steps for defined processes.
  • Reporting. Operational, management and regulatory reports drawn from the loan records.

Not every lending platform includes every item above, and not every lender needs them. Start from your own products and processes, then confirm which functions each candidate provides and how they are licensed. The business software hub covers the wider set of line-of-business systems if lending is one part of a larger review.

When do your current tools need a closer look?

There is no universal loan-count threshold for moving off spreadsheets. Spreadsheets can calculate and validate rules. Their weak points lie in control and continuity, and dedicated software does not remove those risks by itself either. Review the following when managing or verifying the book becomes difficult:

  • Product complexity. New loan products, fee structures or repayment options that the current model handles with workarounds.
  • Corrections. Adjustments, reversals and rework that take time to trace or explain.
  • Manual reporting. Month-end and regulatory reports rebuilt by hand from several sources.
  • Access and change history. Limited control over who can change a figure, and little record of who did.
  • Recovery. Uncertainty about restoring the records after a mistake or a failure.
  • Dependence on one person. A model that only one staff member understands well enough to maintain.

Record the tasks that take the longest and the controls that are missing. A new platform should address those requirements. Moving an uncertain process into software does not make it correct.

What should you document before speaking to suppliers?

A short requirements pack gives every lending software supplier the same brief and makes their answers comparable. It does not need to be a formal specification, but it should describe how the business lends today and what it expects to change.

  • Products and terms. Each loan or account type, with its interest basis, fees, repayment options and any security held.
  • Calculation rules. How interest accrues, how payments are allocated, when fees apply and how arrears are measured.
  • Exceptions. The events that need special handling, such as hardship arrangements, reversals, restructures and early settlement.
  • Reports. The operational, management, investor and regulatory reports the business produces, and who relies on each one.
  • People and roles. Who enters, approves, reviews and exports information, and which tasks need a second person.
  • Connections. The accounting, payment, document and communication systems that exchange records with the loan book.
  • Records to keep. The history, documents and evidence that must remain retrievable after the move.

Mark each item as essential, important or optional. A requirement that only one supplier can meet is worth questioning, and a requirement no lending software meets as standard may point to a process change rather than a software change.

How do you test the lending model before comparing features?

Document your products, interest, fees, repayment allocation, arrears, approvals and records first. Then ask each supplier to demonstrate representative accounts and exceptions, not only a standard loan that pays on time.

Lending software demonstration scenarios: standard loan, missed payment, reversed payment, rate or term change, early settlement

A small demonstration pack can describe a standard loan, a missed payment, a reversed transaction, a permitted rate or term change and an early settlement. Use the cases that match your products. An investment or deposit book may need different scenarios.

For each case, record the terms, the events, the expected output and the explanation you would expect behind it. Then compare expected and actual results, and check the history behind each result, not just the final balance. Software applies configured rules to recorded transactions. Incorrect configuration, late or duplicated transactions and manual adjustments can all affect the outcome, so the lender approves the requirements and the acceptance results.

Use anonymised or synthetic data in demonstrations. Where live records are needed later in a project, agree a secure route for them first.

How does an account move through its lifecycle?

A loan passes through application and assessment, approval and drawdown, active servicing, arrears handling where needed, and settlement or closure. Good lending software carries the account through those stages on one record, and the selection question is whether it does so for your products and rules.

Historical balances and the rules applied at the time matter as much as the current balance. Ask how the system explains a past figure after a rate change, a reversal or a hardship arrangement. Compliance checks run across the whole lifecycle rather than at a single late stage, and a loan renewed on new terms may need a new agreement or process rather than an administrative close and reopen.

What should you check for compliance and records?

Software can support calculations, documents, workflows and reporting, but the lender keeps its legal responsibilities. The FMA’s lender responsibility principles describe duties that apply before and throughout lending, not simply the presence of a report. The FMA took over regulation of the Credit Contracts and Consumer Finance Act (CCCFA) from the Commerce Commission on 1 July 2026, as the transfer of responsibility notice explains, so current guidance comes from the FMA.

Identify the obligations that apply to your products rather than assuming every lender has the same consumer credit duties, and have the relevant requirements reviewed before they are configured. Then treat the audit history as something to verify:

  • What is recorded. Which actions, decisions and changes the system captures.
  • Who and when. The user behind each action and a reliable timestamp.
  • Changes. How edits to loan terms, settings and records are tracked.
  • Retention. How long records are kept and in what form.
  • Retrieval. How a past record can be found and produced when it is requested.

A workflow feature can support defined steps and recorded outcomes, but its presence does not prove that every obligation is met or that every process runs without staff involvement.

How should lending software connect to accounting and payments?

A general ledger covers accounting, financial reporting and reconciliation. A lending system manages loan-specific records and servicing. The two may share some functions or connect, depending on the products involved, and a transfer between them does not on its own leave both systems in agreement.

For each connection, confirm the interface, fields, permissions, licences, timing and error handling. Agree which system owns each record, how duplicates are handled and how the two are reconciled. Business software integration covers that design and support work.

Configuration may meet a requirement, and a process change may meet another. Where a confirmed requirement remains unmet, a supported extension through custom software development can be considered once feasibility, rights and maintenance are agreed.

What should a lending software demonstration cover?

Use this checklist to prepare a supplier discussion. It helps compare platforms on the same terms, and it is not a compliance certificate.

Check What to demonstrate or agree
Products and modules The actual loan and account types required, including any optional origination, deposit or workflow modules.
Calculations and exceptions Representative interest, fees, allocation, reversals, arrears and settlement outcomes against expected results.
Records and history How a past balance and decision can be explained, with transaction, document and change history retrievable.
Access and approvals Who may view, create, amend, approve or export information, and how actions are recorded.
Connections The fields, timing, owners, validation, duplicates, rejected transfers and reconciliation for each interface.
Migration acceptance Accounts and history moved, records left behind, balance checks, sample scenarios, sign-off and fallback.
Hosting and continuity Application and infrastructure responsibility, backups, tested recovery, support hours and escalation.
Cost and exit Licences, modules, project charges, running costs, future changes, usable exports and ongoing access to records.

The checklist works whether you are evaluating finPOWER Connect or another platform. Record the answer to each row in writing so the proposals can be compared on the same terms.

How do you separate the requirement from the product pitch?

A feature can exist without fitting your exact workflow or contract, and a polished demonstration can hide how much work sits behind it. For each requirement, ask the supplier to say which of these applies:

  • Standard. Included in the base product and available without further setup beyond normal configuration.
  • Optional module. Available at an additional licence charge, and possibly with its own implementation work.
  • Configuration. Achieved through product settings, with the settings documented and owned by someone after go-live.
  • Supported extension. Custom work that the product allows, with agreed maintenance when the product is updated.
  • Separate service. Provided outside the platform, such as a reporting tool, a payment provider or a document service.

Identify any recurring maintenance and record unresolved gaps rather than treating a successful demonstration as approval of the whole implementation. Because Exodesk resells finPOWER Connect, this guide is not a ranking of every lending software product. The questions are the same whichever platform you assess.

Who looks after hosting, recovery and access?

A loan book is a record the business must be able to produce long after a loan closes, so responsibility for the lending software and the platform underneath it needs to be clear before go-live. Agree in writing who looks after each layer:

  • Application. Product updates, configuration changes and vendor support, and who approves each change.
  • Infrastructure. The servers or cloud service, security updates, monitoring and capacity.
  • Backup and recovery. What is backed up, how frequently, where copies are kept and when a restore was last tested.
  • User access. How accounts are created and removed, which roles can approve or export, and how access is reviewed.

Ask how long the business could work without the system and how much recent work it could afford to re-enter, then check that the recovery arrangements match those answers. Support hours and escalation routes matter in particular at month-end and when a borrower is waiting on a payout figure.

How do you plan the loan book migration?

A migration moves records, history and working processes, so plan it as a project with clear acceptance criteria rather than a data import.

1

Agree the scope of the move

Decide which accounts, transactions, documents and history will move, what stays accessible in the old system and the planned cutover point. Name the person who owns the migration and signs it off.

2

Prepare and map the data

Match each field in the current records to its place in the new system, and resolve gaps, duplicates and inconsistent product settings before the trial loads begin.

3

Reconcile and test

Reconcile balances and transactions after each trial load, then test representative account types and exceptions. Resolve unexplained differences before sign-off, not after go-live.

4

Cut over with a fallback

Agree how work done during cutover is captured and what the fallback is if acceptance fails. Prepare staff training, permissions and recovery before daily use begins.

How do you compare the full cost and support?

Separate lending software licences and modules from the project and running costs, and set them against realistic benefits. Time recovered can improve capacity, but it is not automatically a payroll saving.

  • Platform. Licences, modules and any usage-based charges.
  • Project. Configuration, integration, migration and training.
  • Running. Hosting, maintenance, support and future changes.
  • Exit. Usable data exports and ongoing access to historical records.

Ask who maintains product settings and integrations, who handles vendor updates, and how faults and reporting questions are escalated. Support hours, change charges, source ownership for any extensions and data exports belong in the proposal.

Lending software support from Exodesk

As an Authorised Reseller of finPOWER Connect, Exodesk implements, configures, integrates and supports the platform for lenders. If it is on your shortlist, our finPOWER Connect page covers the product, implementation and a demonstration enquiry.

Exodesk has supported New Zealand businesses since 1989. Today, our Christchurch and Dunedin teams support businesses nationwide.

NEXT STEP

Is finPOWER Connect on your shortlist?

Describe your loan products, current system and the scenarios you want to check, and we can arrange a demonstration. Please keep borrower records and account exports out of the enquiry form.

Or see our business software services.

Frequently Asked Questions

What is lending software?

It manages loan records and servicing, such as schedules, transactions, balances and arrears. Origination, deposits, workflows and reporting may also be available. Functions vary by product, modules and configuration, so check the requirements for your lending model.

When should a lender move beyond spreadsheets?

There is no universal loan-count threshold. Review complexity, corrections, reporting, access, change history, recovery and dependence on one person. A new platform is justified by the requirements it addresses, not simply the size of the loan book.

Is lending software the same as accounting software?

No, although functions can overlap. A lending system manages loan-specific records and servicing, while accounting software supports the wider ledger, accounts and financial reporting. Check which system owns each record and how transactions are reconciled where they connect.

Can lending software connect to our existing systems?

Possibly, where supported interfaces, licences and access meet the required flow. Agree fields, timing, permissions, validation, duplicates and failure handling. Integration can reduce repeated entry, but it does not remove the need to reconcile records or correct source errors.

Does lending software guarantee compliance?

No. It can support configured calculations, documents, workflows and records. The lender retains responsibility for decisions, disclosures and the requirements applying to its products, so confirm the rules, test the setup and check how records can be retrieved later.

Can lending software support CCCFA responsibilities?

Relevant systems can help keep required records and produce documents or workflow prompts. What is needed depends on the credit products and the obligations that apply. A module or report does not prove compliance, and the lender must approve and maintain the relevant requirements.

How long does a lending migration take?

Timing depends on product complexity, data quality, history, interfaces and testing. Agree the accounts and records to move, reconciliation, acceptance, cutover and fallback. Importing data is only part of the work, and unresolved differences need attention before release.

Will configuration be enough or will we need development?

Start by checking standard functions and optional modules against the requirements. Configuration may be enough, and a supported extension or integration may address a remaining gap. Confirm feasibility, rights and maintenance before commissioning development rather than assuming either route is required.

Where does finPOWER Connect fit?

It is a loan and deposit management platform developed by Intersoft Systems. Exodesk is an Authorised Reseller that implements, configures, integrates and supports it. The dedicated finPOWER Connect page covers the named product, implementation and demonstration enquiries.

How much does lending software cost?

Compare licences and modules with configuration, migration, integration, hosting, training and support, and include future changes and exit costs. The price depends on the actual requirements. Expected time savings or lower rework should be assessed against the full cost, not assumed as payback.

Contact us or call 0800 396 337 to discuss your products, current system and the scenarios you want to check.

Start typing and press Enter to search

Supply chain security: illustrative map of a business connected to its suppliers, with one supplier incident highlighted.Windows Server end of life: flat vector of an unsupported server with a warning, and arrows to an upgraded server, the cloud, and a cloud suite. Call Us Now