Xero
AvailableIn Sydney, Auckland and Manchester, the client's ledger question has one answer.
Written for factors and asset based lenders funding businesses in Australia, New Zealand and the United Kingdom, where a request for a client’s accounting file is a request for a Xero organisation nine times out of ten.
FactorFox connects to it read only, per client, on the client’s own consent, and feeds the same intake rail everything else in the platform feeds. Nothing is ever written back.
What crosses, and which way
- Inbound
- Contacts and accounting transactions, read only, on the client's consent
- Outbound
- Nothing. There is no write path to a client ledger
- Held per
- Client. One connection, one consent, one revocation
- Applied by
- A named person, through the intake rail, after the gates
Available today. Requires your own Xero application credentials.
The market this is written for
A funder outside the United States spends the first meeting explaining what they can accept.
Ask an Australian or British operator what their intake looks like and you will hear about emailed debtor listings, PDFs exported at the end of a month, and a client who is genuinely confused about why the funder cannot simply look at the same screen their bookkeeper looks at. The client is not being difficult. They keep their entire financial life in one place and they expect their funder to meet them there.
The reason most platforms cannot is that they were built around a United States accounting stack and treated everywhere else as a configuration. So the Xero connector arrived late, kept its own shape, and produced a second class receivable that the analytics did not fully understand.
Here the connector is late to nothing. Xero receivables land in the same normalised shape as every other channel, which means concentration under one debtor name across several clients works whether those clients are in Brisbane or Birmingham, and dilution movement means the same thing in both. A client who switches ledger next year changes how their data arrives and changes nothing about how they are underwritten.
The rest of the local stack is present too. PPSR search, registration and verification statements with expiry watched rather than remembered. APCA direct entry files in CS2 format for Australian banks. The security position and the payment rail are not add ons bolted onto a United States product, and neither is the ledger.
What moves
Contacts and accounting transactions, and what the platform makes of them
Consent is given once by the client, against one organisation, for reading. Everything below happens on the FactorFox side of that boundary.
Contacts to parties
A client's customer list resolves into debtors as parties. The same debtor funding two of your clients is one party with one exposure, which is the only way concentration under one name is visible at all.
Transactions to receivables
Open invoices with their amounts, issue dates, due dates and credit notes, mapped into the same receivable structure paper and portal submissions land in.
Idempotent on re run
Records are keyed on the identifiers Xero assigns, so a second sync updates and inserts rather than duplicating. Running it twice is uneventful, which is the correct outcome for a sync.
A proposal, not a posting
The sync raises a proposal in the intake rail describing what it would add, change and retire. Nothing reaches your book until an operator with the authority applies it.
The gates still run
Duplicate and near duplicate detection, cross portfolio fingerprinting, size deviation against the client's own median, submission timing. Arriving through an API makes an invoice convenient, not verified.
Dated and reversible
The last successful sync is dated on the client record, and the connection can be ended from either side at any time without disturbing what is already on your book.
The read only rule
Never writing to a client ledger is a commercial position, not a technical limitation.
It would be straightforward to write assignment notices, apply payments or mark invoices as factored inside a client’s Xero organisation. Several products do. We decline, and the reason is worth stating plainly because it is the kind of thing buyers only think about after it has gone wrong.
The scopes are read only and there is no write path behind them. This is not enforced by a setting somebody could change during an implementation. There is nothing to enable.
Consent is held per client and revocable from either side. Your client can disconnect from inside Xero without calling you, and that is intentional. A connection a client cannot end is a connection they will hesitate to start, and hesitation at onboarding is expensive for both of you.
Revocation does not rewrite history. Receivables already applied stay on your book, because a person applied them after the gates rather than a feed mirroring them in. The difference matters on the day a relationship ends badly: your record of what you funded is yours, and it does not depend on continued access to somebody else’s accounting system.
What a write path would cost you
Their accountant reconciles that file. Their bank reads it. Their tax position is filed from it.
A funder with a write path is one integration bug away from being the reason a client’s accounts are wrong, and no advance rate compensates for that conversation.
Around the ledger
What else an Australian, New Zealand or British operation runs on
A Xero connection is one row. These are the rows next to it, with the status each one actually holds.
| Row | Status | What it gives you |
|---|---|---|
| PPSR | Available | Australian registered security interests: search, registration and verification statements, with priority and expiry watched rather than assumed. |
| APCA direct entry | Available | ABA files in CS2 format with one hundred and twenty character records, generated from released items only, with the same release control in front of them as every other rail. |
| Probity network | Available | Debtor payment behaviour from across the FactorFox network. No vendor, no contract, no per check charge, and nothing about your book leaves your tenant. |
| Creditsafe | Contract required | Commercial credit on debtors in your markets. The rail is built and answers not configured until you hold a contract and keys. |
| AML and sanctions screening | Available | Screening at onboarding and daily rescreening afterwards, with results kept as versioned evidence rather than overwritten. |
| Microsoft 365 | Controlled release | Graph mail, calendar projection and Entra ID federation, for operations running on a Microsoft tenant, which in this market is most of them. |
Straight answers
What a funder outside the United States asks
Is this the same integration as QuickBooks with a different name on it?
It is the same rail and a different connector. The proposal path, the gates, the normalised receivable and the audit are shared deliberately, because a client who migrates ledgers should not become a different kind of client. What differs is the vendor relationship, the consent flow, the shape of what Xero returns, and the fact that most books it reads sit outside the United States.
Can FactorFox raise an invoice or apply a credit in our client's Xero?
No. The scopes are read only and there is no code path that writes. That matters more in a Xero market than it sounds, because your client's accountant works in that file, often weekly, and a funder that mutates it becomes part of every reconciliation argument and eventually part of a dispute about who changed what.
What happens when a client disconnects us from inside Xero?
The connection ends and FactorFox says so. Connection state is held per client, so one client revoking changes nothing for any other. Receivables already applied to your book stay exactly where they are, because they were applied by a person through the intake rail rather than mirrored from a live feed. Nothing rolls back, nothing vanishes, and the last successful sync is dated on the client record.
We fund Australian and United States clients from one operation. Does that work?
Yes, and the ledger is the least of it. Australian direct entry files are produced in APCA CS2 format with one hundred and twenty character records while United States funding produces NACHA PPD at ninety four, and PPSR search, registration and verification statements cover the security position with expiry watched rather than diarised. The release control, four eyes and audit are identical on both sides, because the discipline should not depend on which country the money leaves from.
Our debtors are in New Zealand and the United Kingdom. What credit data can we get?
Probity network answers immediately and costs nothing, because it reads how a debtor has actually paid across the FactorFox network rather than buying an opinion about them. Creditsafe covers commercial credit in those markets and its rail is built, but it answers not configured until you hold a contract and keys with Creditsafe. The screen shows it greyed with the vendor named, so an underwriter knows a source exists and is switched off.
Does the client need a particular Xero plan or an adviser relationship with us?
The connection is authorised by the client from their own Xero session against the organisation you are funding, and no adviser or partner relationship is required for it. What you do need is your own application credentials with Xero, the same posture as every other accounting connector on this site. Your name is on the consent screen and the vendor relationship is yours.
Related
Bring a real Xero organisation to the demonstration.
A sandbox proves the connection works. A client's actual file, with its duplicated contacts and its optimistic due dates, proves what the intake rail does about it.