Architecture
Where does the intelligence live?
The question the industry has been asking vendors is whether their software has AI. It is the wrong question, and it is answerable by almost anybody. Connecting a model to software is a week of work. It is a different exercise from architecting software around one.
The question that separates them is where the intelligence sits relative to the ledger. This page is the honest answer for FactorFox, including the parts that are architecture rather than magic, and the test you can run on any vendor who tells you the same thing.
Two architectures
Same demo, different buildAI enabled
A model is connected to the software.
It is handed a question and some context. It can summarise, draft and answer.
AI native
The intelligence is part of the operating system.
It reads the ledger, applies the policy version in force, writes append only, and refuses to show a change it cannot prove.
And underneath both
The model is the engine. It should be replaceable without replacing the vehicle.
The distinction
Two architectures that look the same from the outside.
AI enabled means a model is connected to the software. The model sits beside the system and is handed a question along with whatever context the integration passes it. It can summarise, it can draft, it can answer. What it cannot do is see the ledger the way the ledger sees itself, because it was never given that seat.
AI native means the intelligence is part of the operating system. It reads the same records, applies the policy version that was in force at the time, writes its observations append only so an audit trail cannot be rewritten afterwards, and refuses to display a change it cannot prove. That is a different build, and it is the reason a conclusion here opens onto its own evidence rather than onto a restatement of itself.
Both are real products. Both will demonstrate well for twenty minutes. The difference shows up in week five of an implementation, when somebody asks the software why it reached a conclusion and needs an answer that will survive an examiner.
The test
Ask any vendor to show you the evidence behind a conclusion the software reached on its own.
Software with a model attached will show you the answer again, worded differently. Software with intelligence in the architecture will open the records, the policy version that applied and the reason it was reached.
We have read this shape before
The same architectural bet, twice.
This industry has already lived through one shift of exactly this kind, and the lesson from it is not about technology. It is about what you allow your software to depend on.
Then · the cloud
Software was written for an operating system.
You did not buy factoring software. You bought factoring software for Windows, and you inherited the upgrade cycle, the hardware and the migration that came with it. What the cloud actually did, underneath the marketing, was make the application independent of the operating system underneath it.
FactorFox moved on that in 2002.
Now · AI native
Software is being written for a model.
A platform built around one model family inherits that family’s roadmap, its pricing, its licensing terms, its deprecations and its outages. The dependency is invisible while the model is good and expensive the moment it is not.
FactorFox is built to be independent of any single model. Same architectural bet, made twice, twenty four years apart.
Worth remembering
Nobody could have picked the winner in 1999.
Lycos, AltaVista, Excite and Infoseek all looked permanent at the time. Anyone who had bet their business on the leader of that moment would have spent the following decade migrating off it. What made the web survivable was that it never asked anyone to choose, so the churn happened underneath the applications instead of inside them.
We are not betting on which model wins. We are betting there will always be a better one.
What independence actually buys
Three ordinary operating events, and what they cost you
This is an operations argument rather than a technology one. The value of not being tied to a single model shows up on ordinary days, not in a keynote.
A model has an outage
Model providers have bad afternoons like every other piece of infrastructure. A platform with one path has an outage too, and it lands on the day your team is trying to fund. A platform that can route continues on another path, and records that it did.
A materially better model ships
The interesting question to put to any vendor, including us, is what happens that week. Where the model is a configuration decision, the answer is an evaluation and a change. Where it is an architectural one, the answer is a roadmap item and eventually a migration.
Terms, pricing or licensing change
Commercial terms move. So does what a provider will permit for a given class of data. Independence keeps that a commercial decision you can make on the merits, rather than an ultimatum arriving inside a product you already depend on.
The best model for the job
Models are specialising. That is the opportunity, not the risk.
Adjudicating a funding decision against a policy is a different task from reading a scanned proof of delivery, and neither resembles ranking a collections queue by exposure. The platform routes on the shape of the work.
| Class | What it is good at | Where it does work here |
|---|---|---|
| Reasoning | Multi step judgement, and stating why rather than only what | Underwriting narrative, covenant interpretation, the briefing itself |
| Decision | Applying a written policy consistently to a specific case | Funding adjudication, gate evaluation, exception routing |
| Behavioural | Patterns across time, and how a party acts rather than presents | Fraud signals, promise history, debtor deterioration |
| Document | Extraction, classification, verification and tamper detection | Intake, near duplicate detection, contract reading |
| Quantitative | Arithmetic that has to be right, at portfolio scale | Exposure, concentration, dilution, borrowing base |
| Agentic | Carrying out a sequence of work rather than answering about it | Collections drafting, reconciliation preparation, packet assembly |
| Whatever ships next | Not released yet, and that is the point | Evaluated when it exists, adopted if it earns it |
Routing is recorded with the rest of the evidence. A conclusion can always be traced back to what produced it, including which class of model did the work.
What it looks like when it is real
A factoring agreement is a configuration file nobody has read that way.
Every client agreement you sign already contains the operating rules for that relationship. The advance rate is in there. So is the fee schedule, the discount terms, the reserve, the concentration limit and what happens when an invoice ages past its window. Then somebody types all of it into a system by hand, and a transcription error becomes a funding error four months later.
Give the platform the executed agreement and it reads the terms, including the fees and the discount schedule, and sets the client up against them. Not a summary of the agreement. The terms themselves, configured, with the clause each one came from attached to it.
That is what intelligence being part of the architecture buys. A model connected to the software can tell you what an agreement says. A system with intelligence inside it can turn what the agreement says into the rules it will hold you to, and show you the sentence behind every one of them.
Agreement read into terms
In the product- Advance rateClause 3.1
- Discount scheduleClause 4.2, schedule A
- Fee structureClause 4.4
- Reserve percentageClause 5.1
- Concentration limitClause 7.3
- Ageing and recourse windowClause 9.2
Every configured term keeps a link to the sentence it came from, so a disagreement about what was agreed is settled by opening the clause rather than by memory.
How to check any of this
Architecture claims are easy to make. These are the ones you can verify.
Every claim on this page is checkable, and the checks are the same ones we would apply to anybody. Start with the integration register, where every connection carries one of five status words and eight vendors are named as connections we do not claim. A register that records absences is a register you can trust about presences.
On accounting specifically, FactorFox holds 2 accounting integrations, QuickBooks Online and Xero, both recorded as available, sitting on a true double entry core that has carried this business since 2002. Ask any vendor how many accounting packages they connect to, then ask them to show you the general ledger underneath. The two answers together tell you most of what you need to know about how deep the accounting really goes.
On security, we publish where we actually are rather than a badge. A SOC 2 programme is under way, targeted for completion at the end of 2026, and until a report exists there is no certification claim anywhere on this site. Ask for the report, not the badge, and note whether a vendor separates their own posture from their cloud provider’s. Our security position states both plainly, and how to choose sets out the rest of the questions worth asking.
Straight answers
What operators ask about the architecture
Is model independent the same as saying you do not use AI models?
The opposite. It means the platform is built to use them and to keep using better ones. The intelligence is part of the operating architecture: it reasons against the ledger, the policy version that applied and the evidence underneath, and a model is the engine it uses to do that. Swapping the engine does not change the vehicle. What it means in practice is that the model doing the reasoning is a configuration decision rather than an architectural one, and that decision can be revisited whenever a better option ships.
Why does it matter which model you use if the answers look the same?
Because the answers do not stay the same, and neither do the models. Model families specialise, get retired, change price, change licensing terms and occasionally go down for an afternoon. Software written for one specific model inherits every one of those events. Software written to route across models treats them as supply. The test to apply to any vendor, including us, is simple: ask what happens the week a materially better model ships, and listen for whether the answer sounds like a configuration change or a project.
How do you decide which model handles which job?
By what the job actually is. Adjudicating a funding decision against a policy is not the same task as reading a scanned bill of lading, and neither is the same as ranking a collections queue by exposure. Different classes of model are better at different classes of work, and the platform routes on the shape of the task rather than on a single default. Routing decisions are recorded with the rest of the evidence, so a conclusion can always be traced to what produced it.
Does an AI native architecture mean the software makes decisions on its own?
No, and the asymmetry is deliberate. The platform can stop money on its own authority. Only a named human can let money through. Four eyes applies by default, certain gates cannot be made advisory by any role or configuration, and every conclusion opens onto the evidence that produced it. Intelligence being part of the architecture is what makes that enforceable rather than procedural.
How would I tell the difference from the outside?
Ask where the intelligence sits relative to the ledger. Software with AI connected to it can summarise, draft and answer, because it has been handed a question and some context. Software with intelligence in the architecture can adjudicate, because it reads the same records the ledger reads, applies the policy version in force at the time, and refuses to display a change it cannot prove. The second is harder to build and easier to verify: ask for the evidence behind a conclusion and see whether the system can open it.
Related
Bring your own book, and your own agreement.
Send a slice of open receivables and a client agreement. We will show you what the first briefing says about your book, read the agreement into terms in front of you, and tell you plainly what we could not see and why.