Skip to content
FactorFox

Switching from FactorSoft

What a FactorSoft conversion actually involves.

Written for the operations principal or controller of a factoring company running FactorSoft who has been asked to evaluate a move and has found nothing useful to read. FactorSoft is a capable transactional platform and a lot of good books run on it. This page is not an argument about that.

It is the working document we would give you on a first call: what your data model carries, what it does not, what to export before you talk to anyone, the decisions you will be asked to make, what will not survive the move, and the questions to put to every vendor on your list including us. It is useful whether or not you ever become a customer.

Pre conversion · Extract readiness

Do this first

Three questions to put to your own extract before you put anything to a vendor.

  1. Q1

    What is total funds employed as at the extract moment, derived from the extract alone?

    If this needs a report from the live system, your extract is not yet a baseline.

  2. Q2

    For one named client, what is the reserve balance and what is it composed of?

    The balance will be there. The composition is the part that tells you your real scope.

  3. Q3

    Show the signed assignment notice for one named invoice, from the extract.

    Tests whether the document to transaction link survived the export, which is the thing to know early.

Whatever you decide, the extract is yours

The readiness test we run on a first call. It is a checklist, not a product screen, and it is worth running whether or not you ever move.

Start here

Get your extract before you shortlist anybody.

There is one sequencing mistake that costs more than all the others combined, and it is starting the vendor conversation before you know what you can extract and how long extraction takes. Every timetable anybody gives you is a guess until that is settled, and a guess about a timetable becomes a commitment in a board paper about three weeks later.

Establish which door you are entitled to use. Depending on your deployment and your agreement, you may have direct database access, the product’s own reporting and export tools, a formal extract request to the vendor, or some combination. Find out which, in writing, and find out the turnaround. This single fact drives your whole plan.

Take the extract as at a stated moment and freeze it. A baseline that keeps moving cannot be reconciled against anything. Record the timestamp, store the files unchanged, and work from copies. Everything downstream is measured against that snapshot.

Test it before you trust it. Open the export and try to answer three questions: what is my total funds employed, what is the reserve balance for one named client and what is it composed of, and show me the signed assignment notice for one named invoice. If any of those is hard, you have found real scope while it is still cheap to find.

The strongest position you hold

An operator holding a complete, dated export of their own book negotiates differently with every vendor in the process, including the incumbent. The conversation stops being about whether a move is feasible and starts being about what it will cost and when.

It is also the only version of this exercise where nobody is waiting on anybody. Do it now, even if you decide to stay.

The export list

Fifteen things to pull, and what each one is for.

Pull all of it, even the parts you think you will not need. Re requesting an extract six weeks later is the most avoidable delay in this whole exercise.

What to export from FactorSoft before a conversion, and why
ExportWhy you need it
Client masterIdentity, terms, advance rates, fee arrangement references, status history. The spine of everything else.
Debtor masterThe deduplication problem lives here. Expect the same obligor under several spellings, addresses and identifiers.
Client to debtor relationshipsCredit limits, approved status, concentration positions and any debtor level rules that apply only within a client.
Invoices and schedulesFace value, purchase date, advance paid, due date, status, and the schedule each invoice was purchased on.
Transaction ledgerThe full posting history. This is what lets a period be re posted and compared to a trial balance you already filed.
Cash receipts and applicationsNot net balances. The application detail is what preserves the trail from a payment to the invoices it settled.
Reserve and escrow balancesBalances and, where the structure holds it, composition. Where composition does not exist, that gap is scope.
Chargebacks and disputesAmount, date, reason and disposition. This history is what tells an underwriter whether a dilution pattern is forming.
Verification recordsWhat was verified, by whom, by what method and when. It is both evidence and a picture of your current verification coverage.
Fee and rate configurationEvery schedule, tier, minimum, floor and per event charge. Then the versions, if the system holds them. Usually it holds the current one.
Notes and correspondenceThe least structured and most underestimated item on this list. It carries the collections judgement your team has built up.
Documents and their linkageThe files, and the relationship between each file and the transaction it evidences. Verify the linkage on a sample, not in principle.
Users, roles and permissionsWho can do what today. It is the starting point for role design and it usually surfaces access nobody meant to grant.
Report definitionsNot portable, but a specification. Sort them into read, required by a third party, and abandoned.
UCC, assignment and legal recordsFiling details, dates, continuations and the notices themselves. An examiner will ask, and the answer needs to survive the move.

Names and structures vary by installation and version, so treat this as the list of business objects rather than a list of table names. If something on it does not exist in your extract, that absence is a finding worth writing down.

The data model

What it carries well, and where it goes quiet.

A transactional factoring platform of this generation is built to record what happened, accurately and in order. That is a real strength and it is worth saying plainly, because the parts of your book that are well recorded are the parts that convert without argument.

It carries the transaction spine well. Clients, debtors, invoices, schedules, advances, the posting ledger, cash receipts and their applications, reserve balances, chargebacks. These are structured, they are consistent, and they load. Do not let anyone tell you this part is difficult.

It carries current configuration, not the history of configuration. This is the distinction that produces most conversion variances. A fee schedule is generally held as it stands today. If a client’s pricing changed in the past and no version was retained, the fees you charged before that change cannot be reproduced from the data you now hold. You will find this during the re pricing test, and you will find it whichever platform you move to.

It records the outcome of a decision, not the decision. An override appears as a changed value or an exception flag. What the officer was looking at, which rule was set aside, what authority they held and what evidence sat behind it are not fields, because no system of that era was asked to hold them. This is the gap that evidence linked intelligence exists to close going forward. It cannot be closed backwards.

Eligibility logic frequently lives outside the system. Concentration caps, cross age rules, ineligible categories and debtor limits are often maintained in a spreadsheet that one analyst rebuilds every morning and understands completely. That spreadsheet has to become written rules before it can be run by anything. See borrowing base for the form those rules take once they are explicit.

Notes carry the value that no field holds. Dispute reasons, promise history, the collector’s read on a debtor. It is unstructured and it is where your operational knowledge actually lives. It must come across as evidence, searchable from the client and debtor it belongs to, rather than being discarded because it does not fit a column.

Decisions

Seven things you will be asked to decide, and what each one costs.

These are not technical questions and they cannot be delegated to a project team. Each one is a business decision with a consequence you will live with.

How far back does history come across as live records?

Everything open comes across as live, always. The question is how much settled history joins it as transactional detail rather than as searchable evidence. More live history means richer trend analysis on day one and a longer, more expensive reconciliation. Less means a faster cutover and a period where behavioural comparisons reach back only so far.

Trade off: analytical depth on day one against reconciliation scope.

Which debtor records are actually the same obligor?

Deduplication is proposed by matching and confirmed by a person, never applied silently, because merging two debtor records changes your concentration picture and your credit limits. Somebody senior has to sit with the proposed merges. It is tedious and it is the highest value hour in the project.

Trade off: an unglamorous afternoon against a concentration number you can defend.

Do undocumented fee arrangements get written down or retired?

Most books carry at least a few verbal concessions and grandfathered rates. A conversion forces the question, because a rule that is not written cannot be applied by any system. Writing them down means a conversation with a client. Retiring them means a different conversation with the same client.

Trade off: a set of client conversations now against pricing you cannot reproduce later.

Who owns the reconciliation on your side?

It has to be one named person with the authority to say what is correct, and it should be the controller or someone the controller trusts completely. A reconciliation with no owner becomes a list nobody closes, and a list nobody closes becomes a cutover that happens anyway.

Trade off: a real claim on a senior person's time for the duration of the parallel period.

Which reports are genuinely required by a third party?

Bank reporting, audit schedules and facility certificates have external deadlines and prescribed layouts. Internal reports do not. Sorting them is a half day exercise that determines what must exist at cutover and what can be rebuilt afterwards in the form the new system is better at.

Trade off: half a day of triage against a covenant certificate that is late.

How long does the incumbent stay readable?

Disputes reopen. Examiners ask about periods that predate your new platform. Read access to the old system for a stated period afterwards is a term to negotiate while you still have negotiating position, which is before you give notice, not after.

Trade off: a line item in the budget against an answer you cannot produce.

Do you cut over as you operate today, or as you intend to operate?

The safe answer is to convert your current process faithfully and change how you work afterwards, so that any difference during the parallel period is a data difference rather than a process difference. Changing both at once makes every variance ambiguous, and ambiguous variances are the ones that never close.

Trade off: a slower path to the benefit against a reconciliation that actually means something.

What breaks

Six things that do not convert, on any platform

These are rebuilt rather than moved. Any vendor telling you otherwise is describing a demonstration rather than a project.

Report definitions

Written against one product's internal structures. They are a specification for what to rebuild, and a useful one, but they are not an asset that transfers.

Saved queries and ad hoc extracts

The same problem with less documentation. Usually the fastest to rebuild and the easiest to forget until the person who ran them each Monday asks where they went.

User defined field layouts

Custom fields carry their data. Their layout, validation and the local convention that made them meaningful do not. Establish what each one actually means before it is mapped.

Integrations on direct database access

Anything reading or writing the incumbent's tables directly stops working at cutover. Inventory these early. They are frequently undocumented and occasionally load bearing.

In house scripts and macros

The spreadsheet that rebuilds the borrowing base, the macro that formats the bank file, the script somebody wrote in 2018. These encode real rules and they need to be read before they are retired.

Muscle memory

Real and worth budgeting for. Keystroke habits and screen order are how experienced operators go fast. The vocabulary does not change, but the sequence of a day does.

Timetable

What makes each stage long, and what makes it short.

We do not publish a duration for these, because a published duration would be a number without a source and your book would not match it anyway. What we can tell you is exactly what drives each one, so you can estimate your own before anybody quotes you.

  1. Extract

    Driven entirely by which access door you hold

    Short when you have direct database access and can pull everything in an afternoon. Long when extraction runs through a request queue with a turnaround you do not control. Establish this first, because every other estimate depends on it, and start the request before you have chosen a vendor.

  2. Discovery

    Driven by how much of your operation is undocumented

    Short when fee schedules, eligibility rules and exceptions are written down and current. Long when they live in one analyst's spreadsheet and two people's memory. The honest way to size this is to ask your controller how many client pricing arrangements they could reproduce from the system alone. The answer is your discovery scope.

  3. Mapping

    Driven by account count, schedule count and decision latency

    Mostly proportional to how many accounts and fee schedules you carry. Extended by every decision that needs a person who is difficult to convene. The way to compress this stage is to name the decision makers before it starts and to give them a standing slot.

  4. Trial load and re pricing

    Driven by what the first load reveals, and by how many repeats it takes

    This is the genuine variable in any conversion plan. Re pricing settled invoices against mapped schedules either produces a short difference list or a long one, and the length of that list decides how many cycles follow. A plan that assumes one load is a plan that has not done this before.

  5. Parallel and reconciliation

    Driven by your period close, not by us

    It runs through at least one full close, because a close is the only event that tests everything at once. It ends when the difference list is empty or every remaining item has an owner and an accepted written explanation. Both of those conditions are yours to satisfy, not ours to declare.

  6. Cutover

    Driven by the calendar constraints, and by nothing else

    Between funding runs, after a completed close, away from audit, field exam and facility reporting dates. The incumbent stays readable. Balances are frozen, stated, agreed and signed by a named person on each side.

Diligence

Nine questions for every vendor, with our own answers.

Put these to us and to everyone else you are talking to. Compare the shape of the answers, not the enthusiasm. Where our answer is inconvenient, it is written here rather than saved for later.

Vendor diligence questions and the FactorFox answer
Ask every vendorWhat FactorFox says
Will you re price a sample of our settled invoices and show every difference?Yes, during the trial load, and the difference list is a document you keep. This is the test that finds the expensive problem, so we would rather run it early than be surprised by it in parallel.
Can we see the reconciliation template before we sign?Yes. Each reconciled category, the figure on both sides, every difference with an owner. If a difference is closed, it is closed by a named person deciding, not by a number being adjusted.
What will you refuse to do?We will not plug a variance to make a book tie, and we will not accept an instruction to. We will not import a note as an observation the platform made. We will not claim a source is live when it is dark.
Which of our named requirements are available today and which are planned?We state a status on every integration row and we hold the wording. Available, controlled release, contract required, planned, ecosystem. Ask us to mark up your requirements list with those words and hold us to it.
Can your automation move money without a person?No. The machine may stop money. Only a named human may let it through, four eyes applies by default, and certain gates can never be made advisory by any role or configuration.
What happens when an external source is unavailable?The platform says so and names the source rather than reporting a zero or a stale figure. A covenant that needs data we do not hold reports that it is awaiting a live source. Silence dressed as a number is the failure mode we designed against.
Do your models learn from our outcomes?Not today, and we will not say otherwise. Every weight is a pinned constant. What is true is that every dismissal is recorded with a written reason and a name, which is the raw material a calibration loop needs, and calibration is the next build.
What does your platform cost to run after year one?Ask this of everyone, and include the people whose job exists because the software cannot do something. Our position on what drives cost is written out on the pricing page rather than held back for a call.
If we leave you, what do we take?Your book, your documents, your audit history and your sealed packets. Export is a supported operation rather than a negotiation. A record you cannot take with you was never really yours.

After cutover

What actually changes on the Monday.

The vocabulary is identical. Schedules, advances, reserves, ineligibles, chargebacks and verifications mean what they have always meant. Nobody has to learn a new word for anything, which is why the retraining conversation is shorter than people expect.

The day starts with an answer instead of a queue. A briefing answers six fixed questions scoped to what you are responsible for: where risk is and why, which decisions require you now, what changed since the last brief, where cash is and what can move safely, what is likely next, and whether you are within covenant. The second briefing of the day states the difference rather than restating the book.

Every conclusion opens onto what proves it. A severity, a reason, references into the underlying records and a recommended action with the permission it needs. Risk observations are append only at the database level, and the platform refuses to show a change it cannot prove.

Underwriting stops being an annual event. Continuous underwriting re runs on every material event, versions each run immutably, and reports confidence and coverage separately, so a thin answer is visibly thin rather than quietly wrong.

Exposure is read across the portfolio, not just within a client. Concentration under one debtor name across several clients, duplicate and near duplicate documents across the whole book, payment velocity by obligor, invoice size deviation against a client’s own median. These are the patterns that only exist above the level of a single client file.

The refusal is the point

The moment that explains the difference better than any feature list is watching a release get refused because the person approving it is the person who requested it, with the reason stated and the second officer already notified.

Solo operators are not exempted. An AI counter review is logged where the second name would sit, and it refuses outright when any underlying fact has changed since the request was raised.

Straight answers

What FactorSoft operators ask us first

Can we get our own data out of FactorSoft?

Yes, and you should do it before you shortlist anybody. Your options are usually direct database access if your installation gives it to you, the reporting and export tools inside the product, and a formal extract requested from the vendor. Which of those is available depends on your deployment and your contract, so the first thing to establish is which door you are entitled to use and how long a request through it takes. Everything else in a conversion timetable sits downstream of that answer.

What does a FactorSoft export actually contain?

Structurally, a great deal. Clients, debtors, invoices and schedules, the transaction ledger, cash receipts and their applications, reserve and escrow balances, chargebacks, verification records, notes and stored documents. What it will not contain is the reasoning behind any of it: who approved the exception that let an invoice fund, which version of a fee schedule priced an invoice charged eighteen months ago, and why a particular reserve is being held. Those are the items that make conversions long, and none of them are unique to this platform.

What happens to our custom reports?

Assume they do not move, and plan on that basis rather than hoping. Report definitions are expressed against one product's internal structures, so they are specifications rather than assets. The useful exercise is to sort them into three piles: reports somebody genuinely reads, reports that exist because a bank or an auditor demands that exact layout, and reports that were run once in 2019 and never retired. The second pile is the only one with a hard deadline attached.

What about the documents?

Documents move. The link between a document and the transaction it evidences is the part to verify early, because in many installations that relationship is partly held in file naming and folder structure rather than in a foreign key. Export a sample and try to answer a single question with it: show me the signed assignment notice for this specific invoice. If that takes more than a moment, you have found a real piece of scope.

Will our staff have to relearn everything?

The vocabulary does not change, because it is the industry's vocabulary and not any vendor's. Schedules, advances, reserves, ineligibles, chargebacks and verifications mean the same thing in both places. What changes is where work starts. Instead of opening a queue and working down it, an operator opens a briefing that states what needs a decision today and why, with the evidence attached. Most of the retraining effort is spent convincing experienced people that they are allowed to trust it, which is why the evidence link on every conclusion matters more than the interface.

Is there anything you will not move?

Report definitions, saved queries, user defined field layouts, in house scripts and any integration built on direct database access. Those are rebuilt, not converted. We would rather say so on a public page than discover it with you in week five. Historical records that have no clean structural home come across as evidence attached to the client and debtor they belong to, labelled with their origin, rather than being forced into live transactional records where they would distort a balance.

What should we ask FactorFox before committing?

Ask us to re price a sample of your settled invoices under the mapped fee schedules and show you every difference against what you actually charged. Ask for the reconciliation template before you sign. Ask which of your named requirements are available today and which are planned, and hold us to the words. Ask what we will not move. If any of those answers arrives as reassurance rather than as a document, that is your signal, and it applies to every vendor on your list.

Send us your export and we will tell you what it is missing.

Before any commercial conversation. We will read the extract, name the gaps that will cost you time in any conversion with any vendor, and give you the list in writing. If you decide to stay where you are, you keep the list.