Switching from WinFactor
What a WinFactor conversion actually involves.
Written for the principal or controller of a transportation factoring company running WinFactor who has been asked to evaluate a move. WinFactor is a competent cloud platform with real depth in freight, 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. Where your data actually sits, what the reporting layer will and will not hand you, what the published terms commit to, what has to be rebuilt rather than moved, 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 · The export question
Ask firstThree questions to put to your vendor in writing, while you are still a customer in good standing.
Q1
On exit, what exactly do we receive, and is it records or reports?
Rendered reports answer yesterday's questions. Records answer the ones you have not asked yet.
Q2
Which clause in our agreement says so, and what is the timetable?
If the answer is a page on a website rather than a clause, you do not have a right. You have a hope.
Q3
Does it include closed history, notes, documents and the audit trail?
Open balances are never the hard part. This question is where the real scope of a project is decided.
Ask us the same three
Start here
You are on someone else's infrastructure. Plan from that fact.
The first thing to establish about any conversion is which door you are entitled to use, and on a vendor hosted platform the answer is narrower than on an installed one. WinFactor states publicly that its software runs on the vendor’s cloud infrastructure and that you do not need servers of your own. That is a genuine operational benefit and it is one of the reasons people buy it.
It also means there is no database on your premises, no backup file in your possession and no administrator on your staff who can query the tables directly. Every route to your own records runs through the product or through the vendor. That is a normal position for a modern platform and it is not a reason to stay or to leave. It is a reason to find out the terms early.
What is publicly described. A library of several hundred default reports, and a reporting interface intended for use with business intelligence tools. Client facing financial exports through the portal. Batch payment file generation for banking. Those are real outputs and several of them are useful during a conversion.
What is not publicly described. Any documentation for that reporting interface, any bulk extract capability, any published schema or data dictionary, and any statement in the public terms about what happens to your data when you leave. We checked in August 2026. Absence from a website is not absence from a product, and it is certainly not a defect. It simply means these are questions for your account manager rather than facts you can look up, and you should treat any vendor who cannot answer them in writing the same way.
The one thing to settle first
Before you shortlist anybody, get a written answer to a single question: what will we receive on exit, in what format, on what timetable, and at what cost.
Ask while you are a customer in good standing with time on the clock. The answer is different when you ask it during a notice period, and the difference is not in your favour.
The request list
What to ask for, in the order that makes the rest cheap.
On a hosted platform this is a request rather than a query, so the sequence matters more than it does elsewhere. Ask for all of it at once. Re requesting in week six is the most avoidable delay in this exercise.
| Request | Why you need it |
|---|---|
| Client and debtor masters | Identity, status, terms and the identifiers that hold the rest together. Expect the same obligor under several spellings, which is a deduplication decision rather than a technical one. |
| Client to debtor relationships | Credit limits, buy and no buy positions, approvals and any rule that applies only within one client relationship. |
| Invoices and schedules, open and closed | Open items are never the argument. Ask explicitly whether closed and settled history is included, how far back, and at what level of detail. |
| Cash receipts with application detail | Not net balances. The application trail from a payment to the invoices it settled is the part that makes a period reproducible. |
| Reserve, escrow and unapplied positions | Balances, and composition where the structure holds it. Where composition is not held, that gap is scope and it is better found now. |
| Advances against invoices, and advances against nothing | Fuel advances, cash advances and non factor advances behave differently from an invoice advance and are frequently the last thing anyone maps. |
| Fee, term and commission configuration | Every schedule, tier, minimum and per event charge, plus broker and sales commission arrangements. Then ask whether prior versions are retained. |
| Chargeback history | Amount, date, reason and disposition. This is the history that tells an underwriter whether a dilution pattern is forming, and it is rarely in an open items extract. |
| Collections activity and notes | Pipeline state, next action dates, promises and the collector's written read on each debtor. Unstructured, underestimated, and where your operational knowledge lives. |
| Verification records | What was verified, by whom, by what method and when. Both evidence and an honest picture of your current verification coverage. |
| Documents with their linkage | The files themselves, and the relationship between each file and the transaction it evidences. Test the linkage on a sample rather than accepting it in principle. |
| Assignment notices and legal records | Notice templates, issued notices, filing details and continuations. An examiner will ask, and the answer has to survive the move. |
| Users, roles and permissions | Who can do what today. The starting point for role design, and it reliably surfaces access nobody meant to grant. |
| Report inventory | Not portable, but a specification. Sort into read by somebody, required by a bank or an auditor, and abandoned in 2019. |
| Your contributed credit and payment experience | If debtor scoring is built partly on pooled member data, establish in writing what happens to the payment history you contributed. |
Treat this as a list of business objects rather than a list of file names. Structures vary by configuration and by version. If something on this list does not appear in what you receive, that absence is a finding worth writing down and pricing.
The asymmetry
Every vendor documents the way in better than the way out.
WinFactor publishes a conversion page. It names the systems it has converted books from, including ours, and it states which balances its importer reconciles: open accounts receivable, reserves, rebates, unapplied cash, fuel and cash advances, and miscellaneous charges. That is a more specific public commitment than most vendors in this category make, and it is fair to say so.
Read the list for what it does not contain. Every item on it is a current balance. Closed invoices, historical cash application, chargeback history, collections notes, document images and their linkage, verification records and the audit trail are not named. That may be a scope decision, a page length decision, or simply a list written for the balances a controller checks first. The point is that it is the same list you should be interrogating in the other direction.
This is not a WinFactor problem. It is the shape of the whole industry. Intake is a sales function so it gets a page. Egress is a support function so it gets a clause, and often not even that. We are describing a pattern, not an accusation, and the useful response is not indignation. It is to ask the export question of every vendor on your list, in writing, before anybody has your signature.
Including us. Our position is written on the migration page and in our answers below: your book, your documents, your audit history and your sealed packets, as a supported operation rather than a negotiation. Hold us to that wording the way you would hold anyone else to theirs. A record you cannot take with you was never really yours.
Decisions
Six things you will decide, and what each one costs.
These are business decisions with consequences you live with. None of them can be delegated to a project team, and none of them are technical.
How much settled history arrives as live records?
Everything open comes across as live, always. The question is how much closed history joins it as transactional detail rather than as searchable evidence. More live history means deeper trend analysis from day one and a longer reconciliation. Less means a faster cutover and a period where behavioural comparison reaches back only so far. On a hosted platform this decision is constrained by what you can actually obtain, which is why the request goes first.
Trade off: analytical depth on day one against reconciliation scope.
What happens to the payment rails on cutover weekend?
A freight book funds daily and often outside banking hours. Batch payment files, fuel card arrangements, prepaid card programmes and any wallet product are separate relationships that do not travel with the data. Each is re established, tested with a small live batch, and cut over on a date you choose rather than a date that arrives.
Trade off: a dedicated workstream now against a funding run that does not go out.
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 sits 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 your clients re onboard to a new portal, and when?
Client facing surfaces are a communication project, not a data project. Your clients have logins, habits and in some cases a mobile app they use daily. Sequencing that alongside the ledger cutover is a decision about who absorbs the disruption, and doing both in the same week is a choice rather than a necessity.
Trade off: a longer overall timetable against a support queue you can staff.
How long does the incumbent stay readable?
Disputes reopen. Examiners ask about periods that predate your new platform. On a hosted system you cannot keep a copy running yourself, so continued read access is a contractual term to negotiate while you still hold negotiating position. That 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?
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 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
A library of several hundred reports is a specification for what to rebuild, not an asset that transfers. The triage is worth more than the reports: read by somebody, required by a third party, or long abandoned.
Business intelligence connections
Anything pointed at the incumbent's reporting interface stops returning data at cutover. Dashboards a board sees monthly are the ones to inventory first, because their absence is noticed immediately.
Load management system feeds
Invoice intake from a transport management system is a per partner integration. It is re established rather than moved, and it needs a live test with real files before you rely on it.
Batch payment file formats
The exact layout your bank accepts is agreed between you and the bank, not owned by the software. Re establish it, send a test batch, and get written confirmation before the first live run.
Portal habits
Your clients have a login, a routine and in many cases an app on a phone in a truck. Their experience changes on a date you choose. Communication is the deliverable here, not code.
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, because a published duration would be a number without a source and your book would not match it. What we can tell you is what drives each stage, so you can size your own before anybody quotes you.
- Request
Driven by the vendor's turnaround, not by your effort
This is the stage that differs most from a conversion off an installed system, and it is the one people forget to start early. You are in a queue you do not control. Submit the request before you have chosen a vendor, ask for a committed date, and treat the answer as the first real input to your plan.
- Inspection
Driven by how complete the first delivery turns out to be
Open what arrives and try to answer three questions from it alone: what is total funds employed at the stated moment, what is one named client's reserve balance and what is it composed of, and show the signed assignment notice for one named invoice. Anything you cannot answer is a second request, and second requests are why timetables slip.
- 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. Ask your controller how many client pricing arrangements they could reproduce from the system alone. That answer is your discovery scope.
- Mapping and trial load
Driven by what the first load reveals
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 written by somebody who has not done this before.
- Rails and parallel
Driven by your period close and your funding calendar
Payment rails are tested with small live batches while the ledger runs in parallel. Parallel 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 a written explanation you accepted.
- Cutover
Driven by the calendar constraints and nothing else
Between funding runs, after a completed close, away from audit, field exam and facility reporting dates. Read access to the incumbent is already agreed in writing. Balances are frozen, stated, agreed and signed by a named person on each side.
Diligence
Eight questions for every vendor, with our own answers.
Put these to us and to everyone else. Compare the shape of the answers rather than the enthusiasm. Where our answer is inconvenient it is written here rather than saved for a later call.
| Ask every vendor | What FactorFox says |
|---|---|
| If we leave, what do we take, in what format, and by when? | Your book, your documents, your audit history and your sealed packets. Export is a supported operation rather than a negotiation. Ask us to show you the clause, and ask everyone else to show you theirs. |
| Is that written in the agreement, or is it a statement on a website? | The agreement. A marketing page is not a contractual right, ours included, and the only version that protects you is the one your counsel can point at. |
| Does the export include closed history, notes, documents and the audit trail? | Yes, and the document to transaction linkage comes with it. If a vendor answers this with open items only, that is not a failure, but you have just learned the real scope of your project. |
| 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 meet it in parallel. |
| Which of our named requirements are available today and which are planned? | We state a status on every integration row and hold the wording. Available, controlled release, contract required, planned, ecosystem. Ask us to mark up your requirements list with those words. |
| 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. |
| Who owns the platform, and what is the roadmap commitment? | Fair to ask of anyone, including us, and more pointed for any product that has recently changed hands. Ask for the support model and the product direction in writing, and ask what protects you if two product lines converge. |
After cutover
What actually changes on the Monday.
The vocabulary is identical. Schedules, advances, reserves, chargebacks, fuel advances and verifications mean what they have always meant. Nobody learns 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.
Exposure is read across the portfolio, not just within a client. Concentration under one debtor name across several clients, near duplicate documents across the whole book, payment velocity by obligor, invoice size deviation against a client’s own median. On a freight book these are the patterns that only exist above the level of a single client file, and they are where the losses come from.
Carrier facts are captured, never asserted. Operating authority, insurance currency and safety scores are recorded as what a source said and when it said it. The relevant gate is explicitly forbidden from asserting them as verified. That refusal is deliberate, and the evidence model explains why we would rather report ourselves blind than report a stale figure as current.
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 recorded where the second name would sit, and it refuses outright when any underlying fact has changed since the request was raised.
Straight answers
What WinFactor operators ask us first
Can we pull our own data out of WinFactor ourselves?
Not in the way an operator on an installed system can. WinFactor is delivered from the vendor's cloud, so there is no database on your premises to query and no backup file you hold. What is publicly described is a large library of default reports and a reporting interface intended for business intelligence tools. That is a reporting surface rather than a relational extract, and the difference matters: reports give you rendered answers, an extract gives you the records the answers were computed from. Establish in writing which of those you are entitled to, in what format, and how long a request takes.
Their site advertises a reports interface. Is that enough to migrate on?
It may be, and it may not, and you cannot tell from the outside because there is no public documentation for it. No developer portal, no endpoint reference, no authentication guide, no published limits. That is not unusual for this category, but it does mean the scope of the interface is a question for your account manager rather than something you can research before the call. Ask whether it returns transaction level records or only report output, and ask for the documentation under a confidentiality agreement before you plan around it.
What do the published terms say about getting our data back?
As published in August 2026, the terms and conditions on winfactor.com govern use of the website. They do not address customer data ownership, export, return on termination, retention or deletion. Whatever governs your book lives in your signed agreement, which is not public. This is not a criticism of that company specifically. It is the normal state of this industry, and it is exactly why the clause matters more than the marketing. Read your own contract and find the sentence, or establish that there is not one.
Does the credit data we contributed leave with us?
Ask, and get it in writing. Platforms that build debtor scoring from pooled member payment experience create a genuine question at exit: your own payment history with your own debtors is operating data you generated, and its treatment on departure should be stated somewhere. Nothing public addresses it. It is the question on this page most likely to be met with a pause, which is precisely why it is worth asking early rather than during a notice period.
What about the transportation plumbing?
This is the part people underestimate on a freight book. Carrier payment rails, fuel card arrangements, prepaid card programmes, batch payment file formats and any load management system feeding invoices in are separate commercial and technical relationships. They do not migrate with the data. Each one has to be re established, tested with a small live batch, and cut over on a date you choose. Inventory them in week one and treat them as their own workstream, because the funding run is the thing that cannot slip.
How does the change of ownership affect a decision to move?
WinFactor announced in October 2025 that it had been acquired by Lendscape. The announcement stated that existing customers would continue to receive the same support and service. That is a normal and reasonable thing for an acquirer to say, and we have no basis to suggest otherwise. What it does mean is that product direction questions are legitimate diligence rather than gamesmanship. Ask for the roadmap commitment and the support model in writing, and ask what happens to your agreement if the product lines converge. Ask us the equivalent question about our own ownership.
What should we ask FactorFox before committing?
The same things. Ask what we will refuse to move rather than what we promise to move. Ask us to re price a sample of your settled invoices against the mapped schedules and show every difference before you sign anything. Ask what our own agreement says about export on termination and make us show you the clause. If any answer arrives as reassurance rather than as a document, treat it the way you would treat it from anyone else.
Related
Send us what you get back and we will tell you what is missing.
Before any commercial conversation. We will read the extract, name the gaps that will cost you time in a conversion with any vendor, and give you the list in writing. If you decide to stay where you are, you keep the list.