QuickBooks Online
AvailableYour client keeps their books in QuickBooks. That should not cost you a morning of keying.
Written for the factoring company and the asset based lender, not for the business looking to factor its invoices. If you fund against receivables and your clients run QuickBooks Online, this page describes what connects, what crosses, and what still requires a person.
The schedule that used to be exported, reformatted and emailed arrives structured instead, and then meets exactly the same scrutiny it met when it arrived as a spreadsheet.
Client · Sunline Packaging · Ledger connection
Not configuredQuickBooks Online cannot be connected yet
This tenant has no Intuit application credentials. The connection button is shown, disabled, with the reason attached, because an operator who can see why something is unavailable can get it fixed.
- Missing
- QUICKBOOKS_CLIENT_ID
- Missing
- QUICKBOOKS_CLIENT_SECRET
- Present
- Redirect callback registered
Degrades honestly · names the absent key · no silent failure
Why this exists
The schedule arrives in whatever shape the client's bookkeeper felt like that week.
Column order changes. Debtor names are spelled three ways. Credits are negative in one file and positive in the next. Somebody in your operations team absorbs all of it, every day, and nobody has ever measured what that costs.
The connection
From consent to a receivable your underwriter can use
Six steps. The interesting ones are the last two, because that is where most accounting integrations quietly stop being careful.
- Register
You hold your own Intuit application
Client identifier and secret from your own Intuit developer account, entered once in FactorFox. Your client's consent screen carries your name, and your relationship with Intuit is not mediated by ours.
- Connect
The client authorises from their own QuickBooks session
An operator starts the connection against a specific client record. The client consents in Intuit's own flow. Nobody at your institution ever handles a QuickBooks password, which is the point of OAuth and the reason credential sharing has no place in this workflow.
- Callback
The authorisation returns, the tokens are stored encrypted
The callback exchanges the grant for tokens which are encrypted at rest immediately. They are never written to a log, never rendered on a screen and never returned by any interface, including to your own administrators.
- Refresh
The connection stays alive without anyone re authorising monthly
Refresh runs server side ahead of expiry. A refresh that fails puts the connection into a state that names itself, so the client is asked to reconnect on a calm day rather than on the morning you needed their schedule.
- Sync
Open receivables arrive normalised and idempotent
Invoices, customers, balances and dates map into one internal receivable shape, keyed on the identifiers QuickBooks assigned. Currency, dates and credit notes land in known fields, so a debtor is the same debtor whether the bookkeeper typed a comma in the name this month or not.
- Apply
A proposal, then a person, then the gates
The sync raises a proposal in the intake rail. An operator reviews what it would add, change and retire, and applies it. Everything applied then faces the ingestion gates in full, exactly as if it had arrived as paper.
The normalised receivable
One shape, so an underwriting run never has to know where an invoice came from.
Every path into the book lands in the same receivable structure: a client, a debtor resolved as a party, an amount, an issue date, a due date, a currency and the external identifier of wherever it came from. Paper, portal, SFTP, EDI and QuickBooks all converge before anything looks at them.
That convergence is what makes the analytics honest. Invoice size deviation is measured against the client’s own median, not an industry figure, which requires the whole of a client’s history in one shape. Duplicate detection works across the portfolio rather than within one channel. Dilution movement means something because credits and the invoices they offset are the same kind of object.
And it is what makes the connector replaceable. Nothing downstream of intake knows that QuickBooks exists. A client who moves to a different ledger next year changes how their receivables arrive and changes nothing about how they are underwritten, monitored, verified or collected.
The external identifier is kept because it is the anchor for idempotency, and because when a client asks why FactorFox thinks an invoice is for eleven thousand and their books say nine, the answer should be a specific record in a specific ledger rather than an argument.
Why normalisation is a control
Concentration under one debtor name across several clients is one of the signals that matters most and is hardest to see. It only works if the same debtor resolves to the same party no matter which client’s ledger they arrived from.
A connector that keeps its own private shape for its own invoices takes that signal away from you without ever mentioning it.
Controls
What protects the information, stated the way your reviewer will want it
This integration is available today and it requires your own Intuit application credentials. Both halves of that sentence are on the register.
| Control | How it works |
|---|---|
| Authorisation | OAuth against the client's own QuickBooks session, under your Intuit application. No password is ever handled by your institution or by FactorFox. |
| Token storage | Encrypted at rest. Never logged, never rendered, never returned by any interface. |
| Token refresh | Server side and ahead of expiry. A failed refresh marks the connection as needing reconnection and names it rather than degrading silently. |
| Direction | Read only in effect. Receivable data comes in. Nothing is written back into the client's company file. |
| Idempotency | Every record keyed on the external identifier QuickBooks assigns. Repeated syncs converge instead of duplicating. |
| Application boundary | A sync proposes through the intake rail. A named human applies it, and the audit record carries the actor and the origin. |
| Ingestion gates | Synced invoices face duplicate and near duplicate detection, cross portfolio fingerprinting, size deviation against the client's own median and submission timing checks, in full. |
| Revocation | The client can disconnect from their side and you can disconnect from yours. Receivables already applied stay on your book, because a person put them there. |
| Missing configuration | The exact absent key is named on screen. Unconfigured features report themselves unavailable rather than disappearing. |
| Tenant isolation | Enforced at the database level rather than in application code, identically to every other data path in the platform. |
Straight answers
What an operations lead asks before turning this on
Does FactorFox write anything into our client's QuickBooks company?
No. The direction of travel is one way. Open invoices, customers, balances and dates come across into FactorFox and nothing goes back. That is a deliberate limit rather than a missing feature. Your client's ledger is their record for their accountant, their bank and their tax filing, and a funder that edits it has taken on a liability nobody priced.
Whose Intuit application is the connection made under?
Yours. The integration runs under your own application registered with Intuit, using your client identifier and secret, which means the consent screen your client sees carries your name and the relationship with Intuit is yours to hold. It is one more step at setup and it is the correct one. A connector that runs under a vendor's shared application makes every customer of that vendor dependent on somebody else's standing with Intuit.
What happens if we sync the same client twice?
Nothing duplicates. Every synced record is keyed on the external identifier QuickBooks assigns it, so a second sync updates what it already knows and inserts only what is genuinely new. Run it twice by accident, run it after a network failure, run it every morning: the receivable set converges to the same state rather than growing.
Can a synced invoice skip verification because it came from an accounting system?
No, and this is the question worth asking of every connector you evaluate. A synced invoice faces every ingestion gate a scanned one faces. Duplicate and near duplicate detection, cross portfolio fingerprinting, invoice size deviation against the client's own median, unusual submission timing, and verification where the debtor and the amount call for it. An invoice is not more true because it arrived through an API. It is only more convenient.
Where are the OAuth tokens kept?
Encrypted at rest, and they are never written to a log and never returned by any interface, including to an administrator. Refresh happens server side on a schedule that keeps the connection alive without a person re authorising every few weeks, and a refresh that fails marks the connection as needing reconnection rather than failing quietly on the morning somebody needed the schedule.
What does FactorFox do if the QuickBooks configuration is missing?
It tells you which key is absent, by name, on the screen where you tried to use it. Not a generic failure, not a spinner, not a feature that silently disappears from the menu. Naming the exact configuration that is missing turns a support ticket into a thirty second fix, and it is the same posture every unconfigured rail in the platform takes.
Related
Connect a sandbox company and watch the second sync do nothing.
The most convincing part of an accounting integration demonstration is the boring part: running it again and seeing the receivable count stay exactly where it was.