Integration register
A logo grid tells you nothing. A status column tells you what you are buying.
This is the full register of what FactorFox connects to, organised by the job it does inside a factoring or asset based lending operation rather than by vendor. Every row carries one of five statuses, in a column of its own, next to the name.
That column is the reason this page exists. It is also the reason the rest of the site is worth reading.
How this page is built
Every row below is rendered from one file in the platform repository. There is no second list that marketing maintains, so this page cannot drift away from the product even by accident.
Nothing enters that file without a source in the repository, the integration register, or a dated proof run. Marketing does not get to promote a row. Engineering does.
24 rows · 8 categories · one source of truth
Why the status column
Every competitor publishes a wall of logos. A logo makes one claim, and it is a weak one.
A logo says an association exists. It does not say whether the connector is generally available, sitting quietly with three named customers, waiting on a contract you have not signed yet, or a design document somebody wrote in a planning session. Those four things look identical in a grid, and they are worth wildly different amounts to a buyer scoping an implementation.
So the question gets asked in a sales call instead, answered by whoever is in the room, and never written down. The gap surfaces at week nine of the project, when the connector everyone assumed was shipping turns out to need a contract nobody budgeted for. At that point you have not just lost the connector. You have lost your reason to believe anything else the vendor told you.
We publish the status instead, and we publish it in the place where a buyer is already looking. A status column on a directory page is a small thing to build and an uncomfortable thing to maintain, which is exactly why so few of them exist. It is evidence about how this company counts, offered before you have paid us anything.
The vocabulary is fixed and there are only five words in it. No row is described with a phrase invented for the occasion, because an invented phrase is how available quietly becomes available soon.
The vocabulary
Five statuses, and what each one commits us to
Read these once. Every row on the rest of the page uses them literally.
| Status | What it commits us to |
|---|---|
| Available | It works in the product today. Some available rows need you to hold your own agreement with the vendor, and where that is true the row says so rather than leaving you to find out during implementation. |
| Controlled release | Built, and proven against a deployed service, running with named customers, not yet generally released or listed in a marketplace. It is a real capability with a deliberately small blast radius while it is validated. |
| Contract required | The rail is built and the screen is wired. It answers not configured until you hold a contract and keys with that vendor. You are buying the plumbing, not the data. |
| Planned | Named and designed. Not built. It appears here because the platform already names it on screen as a missing input, and a gap the software admits to is worth publishing. |
| Ecosystem | A sibling product in the FactorEvo network rather than a connector. Shared intelligence, separate product, separate tenancy. |
Category 01
Microsoft 365
Briefings, approvals, mail and calendar inside the environment your institution already runs on.
| Integration | Status | What it connects and what moves | Who feels it |
|---|---|---|---|
| Controlled release | Briefings, signals, assigned work and approvals delivered where your institution already decides. Briefings and signal cards move out to Teams. Acknowledgements, approvals and questions move back in, and every one of them crosses the same application surface a browser click crosses. The Teams door refuses any envelope Microsoft did not sign | Owners and principals, Credit officers, Operations, Anyone approving from a phone | |
| Controlled release | Remittances arrive in a shared mailbox and become proposals, not silent postings. Inbound mail is classified, its attachments preserved as evidence, and a cash application proposal is raised. Outbound notices and demands leave through the same delivery wall as every other channel. Application permissions are least privilege and the capabilities screen shows exactly what the token carries | Accounting, Cash application, Collections | |
| Controlled release | A collections case projects its next contact into the officer's own calendar. FactorFox writes the follow up. The case remains the record of truth. Deleting the calendar event does not close the case | Collections, Account executives | |
| Available | Demonstration and review scheduling against real availability. Availability out, confirmed appointments back. Runs inside your own Microsoft tenant | Sales, Client success |
Category 02
Accounting
Client ledgers synchronised into proposals, never posted to your book without a human.
| Integration | Status | What it connects and what moves | Who feels it |
|---|---|---|---|
QuickBooks Online Your own vendor agreement | Available | Client receivables synchronised from QuickBooks into the intake rail. Open invoices, customers, balances and dates move from the client's QuickBooks company into a normalised receivable. Nothing moves back into the client's books. Tokens are encrypted at rest and never logged or returned | Operations, Account executives, Your clients |
Xero Your own vendor agreement | Available | The same receivables rail for clients who run Xero. Contacts and accounting transactions in, read only, on the client's consent. Read only scopes. FactorFox never writes to a client ledger | Operations, Account executives, Your clients |
Category 03
Credit and risk
Commercial credit, network payment behaviour and lien position at the moment a party is created.
| Integration | Status | What it connects and what moves | Who feels it |
|---|---|---|---|
| Available | Debtor payment behaviour drawn from the FactorFox network itself. Nothing leaves your tenant. The network plane already knows what it knows about a debtor. No vendor, no contract, no per check charge | Credit officers, Underwriters, Collections | |
Creditsafe Your own vendor agreement | Contract required | Commercial credit on debtors, run at the moment a debtor is created. Company identity, score and payment rating in, attached to the debtor file as evidence. The rail is built and answers not configured until you hold a contract and keys | Credit officers, Underwriters |
Dun and Bradstreet Your own vendor agreement | Contract required | United States client credit at intake. Business identity and credit in, attached to the client file. Same posture as every other bureau rail. No keys, no silent behaviour | Credit officers, Underwriters |
| Available | Federal and state tax lien position on a prospective or existing client. Lien records in, attached to the client file and to the underwriting run that used them. Captured at run time and pinned to the decision | Underwriters, Credit officers | |
| Available | Additional client side risk assessment offered at intake. Assessment in, attached to the client file. Same run time capture and same evidence binding as every other check | Underwriters |
Category 04
Banking and payments
Payment file generation for the rails your bank actually accepts, with release control in front of them.
| Integration | Status | What it connects and what moves | Who feels it |
|---|---|---|---|
| Available | PPD credit files generated for your originating bank. A payment file out. Nothing about your bank relationship moves in. Ninety four character fixed records, blocked correctly | Treasury, Accounting | |
| Available | Australian ABA direct entry files, CS2 format. A payment file out, in the format Australian banks accept. One hundred and twenty character records | Treasury | |
| Available | Wire instruction export for same day movement. Instructions out, formatted for your bank's upload. Bank account changes sit under a human only hold before any wire can reference them | Treasury | |
| Available | Remittance advice and delivery status from trading partners. Remittance detail and shipment status in. Proposals, never silent postings | Accounting, Operations | |
| Planned | Bank feed for lockbox flow and client cash verification. Not built. Declared in the underwriting engine as a source that is not wired. Named here because the platform names it on screen. Nothing about it is described as working | Credit officers, Treasury |
Category 05
Transportation
Carrier and broker identity, and freight claim verification with provenance.
| Integration | Status | What it connects and what moves | Who feels it |
|---|---|---|---|
| Available | Carrier and broker lookup on both the client and the debtor side. Registration identity in, attached to the party file. Operating authority currency, insurance currency and safety scores are not asserted | Underwriters, Credit officers, Operations | |
| Available | Freight claim verification with provenance. A claim goes out for verification. A verdict comes back with the provenance behind it. Verification runs capture evidence at run time and are never re fetched | Underwriters, Operations, Fraud review | |
FactorEvo | Ecosystem | The transportation specialty finance sibling, built on the same intelligence layer. A shared intelligence layer, not a connector. Separate product, separate tenancy | Transportation factors |
Category 06
Document intake
Every door a document arrives through, held to the same evidence standard.
| Integration | Status | What it connects and what moves | Who feels it |
|---|---|---|---|
Email, portal and SFTP intake | Available | Every door a document can arrive through, held to one evidence standard. Documents in, with their original preserved and their classification recorded. Near duplicate detection blocks at verification | Operations, Client success |
Language model extraction | Available | Model based parsing of invoices, bills of lading and rate confirmations. Document text out to the configured endpoint, structured data back under a strict schema. Every model output passes deterministic re validation before it touches the book | Operations |
Category 07
Identity and access
Your directory proves who someone is. FactorFox decides what they may do.
| Integration | Status | What it connects and what moves | Who feels it |
|---|---|---|---|
| Available | Federated sign in over OIDC and SAML, configured per tenant. Identity assertions in. No directory data is copied into FactorFox. Microsoft proves identity. FactorFox grants authority, and the two are never the same decision | IT and security, Every user |
Category 08
Compliance and reporting
Registered interests, screening and the records an examiner asks for.
| Integration | Status | What it connects and what moves | Who feels it |
|---|---|---|---|
PPSR | Available | Australian registered security interests: search, registration and verification statements. Search and registration out, verification statements and expiry watch back. Priority and expiry are watched, not assumed | Credit officers, Compliance |
AML and sanctions screening | Available | Screening at onboarding with daily rescreening thereafter. Party identity out, match results back, attached to the party file. Results are evidence, versioned, and never overwritten | Compliance, Credit officers |
The absence list
What FactorFox does not connect to, named on purpose.
These products get asked about often enough that their absence deserves a sentence rather than a silence. None of them is connected to FactorFox today. Not partially, not through a partner, not by an import somebody built once for one customer and quietly stopped maintaining.
Publishing that costs a conversation occasionally. It is still the better trade, and the arithmetic is not close. An extra logo buys a moment of comfort during a demonstration. A named absence buys the buyer a decision they can actually make, and it buys us the right to be believed about every row above it.
If one of these matters to your operation, raise it during the evaluation. Some are ordinary integration work and we will tell you what building one takes. Others we have chosen not to build, and we will tell you why. Either answer is available to you before you sign, which is the only point at which an answer is worth anything.
The same discipline applies inside the product. A check you have not bought is shown greyed with the vendor named, because a greyed row teaches an operator something true and a hidden feature tells them something false.
Not integrations
- NetSuite
- Sage
- Ansonia
- LoadConnex
- AtoB
- Fairlanes
- TriumphPay
- Decipher Credit
This list lives in the same file as the register above, so a row cannot creep back in without somebody removing it here first.
Straight answers
What buyers ask about this register
What does contract required mean for our project plan?
It means the engineering is done and the commercial step is yours. You sign with the vendor, you receive keys, you enter them, and the check starts answering. Until then the screen shows the check as not configured, with the vendor named, so an underwriter can see that a source exists and is switched off rather than believing it was never offered. Nothing about the timing of your contract changes the code.
Which rows need us to hold our own vendor agreement?
QuickBooks Online and Xero, because the connection runs under your own application registered with Intuit or Xero rather than under ours. Creditsafe and Dun and Bradstreet, because bureau data is licensed to the institution that consumes it. Every one of those rows carries the note on this page. Probity network needs nothing, because it reads behaviour the network already holds.
Will you build a connector we need?
Ask during the evaluation and you will get a straight answer, which is sometimes no. What we will not do is agree in a sales conversation and let the row appear on this page before the code exists. The register is maintained by engineering, and a status changes when the software changes, not when a deal needs it to.
How much of our book does an integration see?
Less than you would expect, and it is scoped per integration rather than granted once. Accounting connectors read a client's ledger and write nothing. Credit rails send a party identity out and bring an assessment back. Payment rails carry a file out and nothing about your banking relationship in. Mail runs under application permissions limited to the features you have enabled, and the capabilities screen shows what the token actually carries rather than what the documentation says it should.
What happens to the platform if we switch an integration off?
It stops, and nothing else does. No part of FactorFox depends on an adapter. Turning off Teams removes Teams. Revoking Graph mail revokes mail and the revocation is stored and audited. Disconnecting a client's ledger leaves every receivable already applied exactly where it is, because a sync proposes and a person applies, so what is on your book was put there by a human decision rather than by a live feed.
Why is a planned row published at all?
Because the platform publishes it internally. The underwriting engine declares a bank feed as a source that is not wired, and covenants that depend on it report awaiting a live source rather than reporting a zero that looks like compliance. If the software is willing to say that to an officer at seven in the morning, the website can say it to a buyer.
Related
Bring the register to your technical review.
Every row here can be demonstrated against a running environment, including the ones that answer not configured. Watching a check refuse to guess is more informative than watching one succeed.