Integrations

Every finance automation vendor publishes an integrations page: a grid of logos, a claim of "seamless" connectivity, and not much else. That page answers a marketing question — does this vendor touch this system? — and nothing else. It doesn't answer the question a controller or a RevOps lead actually has when they're choosing a stack or debugging a broken sync: does NetSuite handle a multi-subsidiary AR payment the same way Sage Intacct does, or does a QuickBooks bill sync fail differently than a Xero one, and why? This cluster exists to answer that second question, one integration-and-workflow combination at a time, and only where the answer is genuinely different from its neighbors.

How we decide a combination deserves its own page

We started with a sheet: 17 integrations down, 5 finance workflows across — AR & collections, AP & invoice processing, revenue recognition & contract-to-cash, payment reconciliation & cash application, and month-end close — for 85 cells. Every cell got scored 0 to 3 on one question: how different is this answer from its neighbor's? A 0 means the page would be identical to the cell next to it with a noun swapped — "how to connect Slack for AR" and "how to connect Slack for AP" turning out to be the same three setup steps regardless of which workflow you're wiring it into. A 3 means the field mappings, the failure modes, or the close implications are genuinely different — QuickBooks's Bill actions have no document-number-based upsert helper the way Invoice and JournalEntry both do, so a retried bill creation duplicates instead of updating, which is a structurally different failure mode than NetSuite's or Sage Intacct's own payment-handling gaps.

Only cells that scored 2 or 3, and that we could back with real evidence, became pages. "I think these are different" wasn't enough — every 2 or 3 had to cite either the vendor's own API or field documentation showing the mapping actually differs, or Loopfour's own integration code showing our product handles the two systems differently. That second source came first: before reaching for a vendor's marketing page, we read our own executor code for each integration — the actual actions, fields, and webhook handlers our runtime uses — because where our product already treats two systems differently, that difference is real and first-hand in a way a comparison chart can't fake.

A worked example of the test

Take revenue recognition across the five ERP and accounting systems in this matrix. NetSuite has no dedicated revenue-recognition action in its integration — reaching its native Advanced Revenue Management module requires a generic SuiteQL query, not a purpose-built endpoint. Sage Intacct has a native Project object carrying its own dimension-based revenue logic, built for project-based and services businesses rather than subscription ones. Rillet has purpose-built contract, amendment, and usage-record actions — by a wide margin the richest revenue machinery in the entire matrix, because contract-to-cash is what the product is built around. QuickBooks and Xero have neither a dedicated action nor documented workarounds specific enough to write an accurate page about, so both of those cells were discarded rather than padded with a generic "QuickBooks doesn't really do revenue recognition" page that would say the same thing twice.

That's three genuinely different pages (NetSuite, Sage Intacct, Rillet) and two honest discards (QuickBooks, Xero) out of five cells in one column — not five pages, and not one page claiming all five systems are interchangeable. Getting that ratio right, cell by cell, is the entire point of scoring the matrix before writing anything.

Why this is hard to copy

Anyone can publish a page that says Loopfour connects to NetSuite, Salesforce, and Stripe. Writing an accurate page about what happens when a Stripe payout doesn't tie to a NetSuite bank deposit requires reading both systems' actual data models, understanding where they disagree, and knowing which of several plausible causes is the common one — not the interesting one, the common one. That's the kind of knowledge that comes from building and running the integration, not from reading either vendor's documentation in isolation. It's also the reason this cluster is deliberately smaller than it could be: of the 85 integration-and-workflow combinations we scored, 40 cleared the bar for having a genuinely distinct answer, and even fewer of those support the full three-question treatment (how to connect it, what breaks, how to reconcile across it) without padding. A comparator can copy our logo grid. It cannot copy a page that only exists because we found a specific field-mapping gap by reading our own code.

The scored matrix

This is the condensed version of the sheet described above — which integrations produced a genuinely distinct answer (score 2 or 3) for which of the five workflows. A blank cell means we looked and the answer was the same shape as its neighbors, or we couldn't evidence a real difference; it isn't an oversight, it's the discipline working as intended.

Avalara is the only integration that scored 2 or higher across all five workflows — not because tax is more important than accounting, but because a tax engine is categorically unlike everything else on this list, so its behavior differs from the field next to it in every direction we checked.

ERP and accounting systems: the same five workflows, five different data models

This category produced the most survivors, and that's not a coincidence — general ledgers are where finance-operations differences are most structural. NetSuite's OneWorld multi-subsidiary consolidation and elimination engine has no equivalent in Xero, which appears to be single-entity by design; Sage Intacct exposes a native, dimension-based project object that carries its own revenue-recognition logic, distinct from NetSuite's schedule-based Advanced Revenue Management module and from Rillet's purpose-built contract-and-usage engine; and NetSuite has no dedicated payment-application action at all — reconciling a Stripe payout against it means falling back to generic records — while Sage Intacct splits AR and AP payments into two separate objects and Xero exposes a dedicated, full-CRUD BankTransaction object built specifically for this. None of these are marketing differentiators. They're structural facts about how each vendor modeled accounting fifteen or twenty years apart from the others, and they directly determine what breaks and how you fix it.

CRMs: real for AR and revenue recognition, near-absent everywhere else

Salesforce, HubSpot, and Attio have essentially no role in accounts payable, payment reconciliation, or month-end close — none of the three exposes a bill, payment, or GL object, so a page claiming otherwise would be inventing a capability none of them has. Where they do differ meaningfully is in how each represents a customer or a deal: Salesforce's Opportunity carries a single lump amount with no way to flag a line item as recurring versus one-time; HubSpot's Quote object does carry that distinction natively, plus real webhook events when a quote changes; and Attio has no fixed deal or opportunity object at all, only a generic, schema-less record type, which means every revenue-recognition workflow built on it starts from a custom object rather than a standard one.

Payments and banking: which side of the transaction you're actually reading

Stripe and Airwallex are both payment processors, but the way each surfaces a payout to your system genuinely differs — Stripe issues invoices and subscriptions directly, functioning as a billing system in its own right, while Airwallex has none of that, positioning it purely as a settlement and payout rail with real-time webhook events where Stripe relies on polling. Plaid is a different kind of integration entirely: it's read-only bank data, the ledger side of a reconciliation rather than the payment side, which is exactly why it's the one integration in this category relevant to month-end close — the open question for Plaid isn't whether a payout matches an invoice, it's whether a pending bank transaction should be included before the period locks.

Communication tools: mostly noise, with two real exceptions

Slack, Outlook, and Gmail all send notifications, and "send a notification about an overdue invoice" is the same page whether the channel is Slack or email — which is why most of this category's cells scored 0. Two cells are real exceptions: Slack supports interactive, in-app approval buttons (a modal that opens from a message, with a hard few-second window to respond before the interaction expires) that neither email tool can replicate, and Outlook is the only one of the three with a calendar-event action, making it the only integration here that can put a close deadline on an actual calendar rather than in an inbox.

Documents and tax: what a signed contract can and can't tell you

DocuSign and PandaDoc are both e-signature tools, but they expose contract data very differently: DocuSign's envelope object is free-form signer fields with no structured price or line-item data, so pulling a transaction price out of a signed DocuSign envelope for revenue-recognition purposes isn't possible without a separate CPQ or contract system. PandaDoc's documents carry structured pricing tables, so the same transaction-price question has a real, if imperfect, answer there — which makes the two vendors' revenue-recognition pages genuinely different pages, not the same page with a name swapped. Avalara sits outside the documents category by function but is grouped here for research purposes; its own API scopes its integration to sales-side documents only (SalesInvoice and SalesOrder), which is a real, code-evidenced fact — not a limitation of Avalara's platform generally, which does support purchase-side tax documents, but a scoping decision specific to how this integration is built today.

What's in this cluster

The three pages live here to start are the strongest, most fully evidenced cells from the matrix above: what actually happens when Avalara rejects a repeated document code, why an uncommitted Avalara transaction won't show up on a sales tax return, and how to sync a Rillet contract amendment into a revenue-recognition schedule without losing track of what changed. More pages are coming from the surviving cells in the table above, roughly following the same three-question shape — how to connect it, what breaks, how to reconcile across it — wherever a cell supports all three without padding.

Not every surviving cell gets all three. A cell that only supports one honest angle — Avalara's AP cell, for instance, is a single diagnostic answer ("no, this integration doesn't calculate use tax on vendor bills") rather than three separate questions — ships as one page, not three thin ones stretched to fill a template. The goal for this cluster is roughly 25 to 30 pages once the surviving matrix cells are fully built out, each one earning its place the same way the first three did: a real difference, a real source, and a question someone actually has.

How to use this cluster

If you're debugging a specific integration failure right now, go straight to the diagnostic pages — they're written symptom-first, name the exact field or status to check, and don't require reading the whole matrix to be useful. If you're evaluating which systems to connect or comparing two vendors in the same category, start with the scored matrix above: a category with no survivors for your workflow (communication tools for month-end close, for instance, outside the two calendar and checklist exceptions) is a reliable signal that the choice between vendors in that category genuinely doesn't matter for that specific workflow, and you can stop researching it and move on to a decision that does.