How to Evaluate Credit Management Software: Ten Questions to Ask Any Vendor

1. Where does the workflow start — the application, or the invoice?

Products in this space are assembled from different starting points, and the starting point determines what is a first-class object in the system and what has been added around the edges later. This is the single most clarifying question you can ask, because the answer predicts most of the others.

Work out where your own problem starts before you ask it. If your pain is genuinely about chasing money that is already owed — aging, dunning sequences, collector productivity — then a receivables starting point may be the right shape for you. If your pain is that four analysts decide differently, that limits are set once and never revisited, and that nobody can reconstruct why an account got the number it did, then the credit application has to be a first-class object rather than a form that feeds a field.

The tell is what the system does with a customer who has no invoices yet. A prospect mid-underwriting, with references out and financials pending, is either a real object with a state and an owner, or it is a row someone is tracking somewhere else until it becomes billable.

• Ask to watch a credit application submitted, scored, routed, approved, and turned into a live limit — end to end, without the demo cutting between screens.
• Ask what the system holds for a customer that has applied but has never been invoiced.
• Ask whether a credit limit is a stored number or the output of a recorded decision.

2. Can you reconstruct why a limit was approved, six months later?

Every demo shows a decision being made. Ask instead to see a decision being explained. Open an account in the demo data that was approved months ago and ask what the system can still tell you: what the score was, which inputs produced it, which policy version was in force, who approved it and under what authority, and what was overridden along the way.

This matters more than it sounds, and it is the question credit managers most often wish they had asked. Write-offs are not usually caused by a bad decision; they are caused by a decision nobody can account for afterwards, which turns a commercial loss into a personal one for whoever signed it. The record is also what makes policy improvable — you cannot calibrate a scorecard against outcomes you cannot reconstruct.

Be specific about overrides. A system where a manager can raise a limit is normal and necessary. A system where that override is stored with a reason, an owner and a timestamp is a different product from one where the number simply changes.

• Ask them to open a months-old decision in the demo tenant, not a fresh one they create in front of you.
• Ask which of these survive: the score, the individual inputs, the policy version, the approver, the authority level, the override reason.
• Ask what happens to the record when the scorecard is later reconfigured — does the old decision still explain itself under the old rules?

3. What happens when one invoice in a balance is disputed mid-collection?

This is the best single stress test in an evaluation, because it crosses three parts of the product at once and it is almost never in the demo script. Ask the vendor to do it live: take an account with several open invoices, dispute one of them for a short-shipment, and then keep collecting.

Watch what happens to the rest of the balance. The failure mode you are testing for is the whole account going quiet because part of it is contested — which is how disputed deductions turn into aged receivables that nobody is working and nobody has decided to write off. You also want to see where the dispute goes: who owns it, what the resolution path is, and whether the credit side of the house can see that this customer's slow payment has a reason attached to it.

Ask what the disputed amount does to the numbers. If a customer disputes $40,000 of a $180,000 balance, a good system can tell you both figures and knows they are different questions.

• Ask them to raise a dispute mid-collection during the demo rather than describing it.
• Ask whether the undisputed balance stays collectible and stays in the collector queue.
• Ask whether the dispute is visible from the credit view, not only the collections view.
• Ask how a dispute affects exposure, aging, and any automated hold.

4. Does it expect to replace the ERP, or work alongside it?

Your ERP posts invoices, holds terms and due dates, and applies cash. Ask directly which system is intended to be the record for each of those after go-live, and listen for whether the answer is confident. Ambiguity here becomes a reconciliation problem that lands on your finance team every month.

Then get concrete about the integration itself, because this is where implementations run long. Which direction does each type of data move? On what cadence? What happens when the same field changes on both sides between syncs? And — the question IT will ask if you do not — who maintains the connector when the ERP is upgraded: the vendor, a partner, or you?

Ask to see the integration rather than a logo wall. A named connector with documented sync domains is a different artifact from a partner badge or a statement that an API exists.

• Ask which system is authoritative for invoices, terms, due dates, and cash application after go-live.
• Ask for the sync direction and cadence per data type, and what conflict resolution looks like.
• Ask who owns connector maintenance through an ERP version upgrade.
• Ask what the integration does when the ERP is unavailable for a day.

5. What is monitored between scheduled reviews?

Most credit risk does not appear at review time. It accumulates in the months in between, while an account that was correctly graded last year slowly becomes something else. So ask what the system is doing during that gap, and be precise about the difference between a dashboard and a mechanism.

A dashboard shows you a deteriorating account if you go and look. A mechanism notices without you. The distinction matters operationally: the first depends on somebody having time on a Tuesday, and the second does not. Ask what can be watched, what happens when a threshold is crossed, and whether crossing it does anything beyond changing a colour on a screen.

Then ask the explainability question again in this context. If an account has been flagged, can someone show you why — the rule that fired and the values it saw — or does the system only tell you that it did?

• Ask which signals can be monitored: payment behaviour, exposure, bureau movement, financial ratios, broken promises.
• Ask what happens automatically when a threshold is crossed — reprioritization, reassignment, an alert with a deadline, or nothing.
• Ask whether you can see why a specific account is on a list, and why another one is not.
• Ask who can change the thresholds, and whether that needs the vendor.

6. What happens at the second entity and the second currency?

If you run one entity in one currency today and expect to keep doing so, skip this section — it is not your problem and you should not pay for it. If you run several, or expect to, it is worth more scrutiny than anything else on this list, because multi-entity behaviour is architectural and cannot be added convincingly later.

The question that exposes the design is simple: can one customer be a customer of two of your entities at once, with separate limits, separate terms, and an exposure figure that means something at both levels? Corporate families make this concrete. If a parent and two subsidiaries buy from three of your divisions, you need the exposure per entity for operational control and the aggregate for the risk decision, and they are different numbers used by different people.

On currency, ask what a consolidated figure actually represents. A total that sums transaction amounts across currencies without stating a rate and a date is a number that will eventually be wrong in a meeting.

• Ask whether one customer can exist across entities with separate limits and a meaningful aggregate exposure.
• Ask what rate and what date a consolidated multi-currency figure uses.
• Ask whether a limit set in one currency is checked correctly against exposure incurred in another.
• Ask what it costs — in configuration and in licence — to add the third entity.

7. How does policy change — configuration, or a release?

Your credit policy will change. Thresholds move, a region is added, a team is reorganised, approval authority shifts after someone is promoted. The question is what each of those costs you once the system is live, and the honest range across products is wide: some changes are a settings screen, some are a support ticket, and some are a release someone else has to schedule.

Ask for the demo to be changed in front of you. Not described — changed. Move an approval threshold, add a risk band, alter who approves above a number, and watch whether it happens in the room. Then ask which changes are not like that, because there will be some, and a vendor who names them clearly is telling you something useful about the rest.

The follow-up nobody asks: who at your company would own this? A system that is configurable in principle but only comprehensible to the vendor is not configurable in practice.

• Ask them to change an approval threshold live in the demo.
• Ask which categories of change require a release, a professional-services engagement, or a support ticket.
• Ask which role at your company would own configuration, and what training that person needs.
• Ask whether configuration changes are versioned and reversible.

8. Who holds the lien clock, and who actually files?

This section only matters if you sell into construction or otherwise hold statutory lien or bond-claim rights. If you do, it matters a great deal, and it is worth being precise, because two genuinely different things get discussed under the same heading.

One is tracking: knowing which job a shipment belongs to, at which tier you sit, what the state requires, which notice is due on which date, and whether the document that protects the right has actually been sent. The other is filing: preparing and submitting the statutory instrument itself, correctly, in fifty different statutory regimes. Ask each vendor which of the two they do, and ask it as an either-or rather than as a yes-or-no, because the softer answer is easy to give and easy to misread.

Then ask the question that catches the real operational risk: can the credit file and the filing record disagree? If the deadlines live in your credit system and the filings happen somewhere else with no data flowing between them, you have two clocks, and the one nobody is looking at is the one that will run out.

• Ask, as an either-or: do you track lien deadlines, perform statutory filings, or both?
• Ask whether deadline dates are calculated from job facts and state rules, or typed in by a person.
• Ask whether filing status flows back so the credit file and the filing record stay in agreement.
• If filing is done by a partner, ask which one, and whether that relationship is contractual or nominal.

9. Is the compliance posture attested, or aligned with?

Security and compliance language is where evaluations most often go wrong, because two very different statements are written in almost identical English. "Aligned with SOC 2 principles" describes a control design. "SOC 2 Type II" describes a completed third-party audit over a defined period, with a report you can read. Both can be legitimate positions; only one is an attestation, and a vendor should be able to say plainly which one they hold without being pressed twice.

So ask for the artifact, not the adjective. If a report exists, ask for it under NDA, and when it arrives read three things before anything else: the audit period and whether it is current, the scope and whether it covers the system you are actually buying, and the exceptions. A report with a clean opinion over a narrow scope tells you less than a report with noted exceptions over the right one.

If a vendor holds a readiness posture rather than a certification, that is a decision, and the useful follow-up is about the trigger rather than the date. What causes certification to happen, and what happens to your procurement if you need it before then? A vendor who can answer that specifically is easier to work with than one who quotes an optimistic quarter.

• Ask directly: is this an attestation, or a control design aligned with the framework?
• If a report exists, ask for the audit period, the scope, and the exceptions — in that order.
• If it does not, ask what triggers certification and what accommodation is available in the meantime.
• Ask how tenant isolation is implemented, and whether the answer is structural or a query condition.

10. What happens to this vendor in three years?

Credit software is not a tool you swap out casually. It ends up holding your policy, your decision history, and the working habits of a team, which means the vendor's own durability is part of what you are buying. Ask about it directly; the answers are more informative than the question sounds.

There is a real trade-off here and it runs in both directions, so decide which side of it you want rather than assuming one is safer. A large, established vendor gives you procurement comfort, a support organisation, and a product that will still exist — and gives you very little influence over what gets built, plus the possibility that your segment is not the one being invested in. A young, founder-led vendor gives you direct access to the people making the decisions and real influence over the roadmap, against a genuine risk profile.

Whichever way you lean, ask the exit question before you sign rather than after. What is the export path for your data, in what format, and how long does it take? A vendor who has thought about how you would leave is usually one who has thought about the rest of it too.

• Ask who you speak to when something is broken at 4pm on a Friday, by role.
• Ask about ownership and funding, and what happens to the product in an acquisition.
• Ask for the data export path — format, completeness, and elapsed time.
• Ask how roadmap priorities are set, and whether a customer of your size influences them.

When you do not need any of this

The honest close: for a meaningful number of the people who will read this, the right answer is to buy nothing, and a guide that will not say so is a sales document.

If you handle fewer than roughly twenty credit applications a month, one experienced person makes the decisions, you run a single entity in a single currency, and your customer base is stable enough that you know the risky accounts personally, then a written credit policy and a well-built spreadsheet will serve you better than any platform on your shortlist, including ours. The coordination problem that credit software solves is not yet your problem, and buying software to solve a problem you do not have costs you the implementation, the subscription, and the flexibility you currently enjoy.

What changes the answer is not the calendar. It is volume, a second decision-maker, a second entity, or staff turnover — the day the knowledge that makes your manual process work stops being reliably present in the building. That is the point at which the process needs to live somewhere other than in a person, and it is the right time to revisit this list.