Why the books beat a card-only feed for a Software Spend Review

Small businesses pay for software in more ways than most owners remember. Some of it is on the company card. Some of it goes out by ACH. An annual contract gets paid by check because that is how the vendor invoices. A direct debit was set up years ago by someone who has since left. Each of those payments uses a different rail, and each one is visible to a different set of tools.

A bookkeeping firm sits in a useful spot here. The books record payments across the accounts the firm keeps, whatever rail they used. That is why ShadowLedger starts a Software Spend Review from the ledger. This piece explains the reasoning and its limits. What the review does with those payments, and why it never claims seats or logins, is in Software Spend Review reads what was paid, not who logged in.

What a card-only feed sees

A card-only spend tool sees the card it issues or connects to. Some also see payments made through their own bill pay. Within that scope, they do a good job: card controls, receipts, and spend limits on those cards.

That scope is the point. A card feed is built around its own card. Software paid some other way is outside that scope. This is not a flaw in that category of product. It is a different job, built for a different buyer.

Where else software payments come from

Software gets paid more than one way. A card-only feed sees its own card, and sometimes its own bill pay. ACH payments, checks, annual invoices, direct debits, and charges on other cards still post to the ledger when the books are kept, so a review from the books reads them in one place.

In a typical client file, recurring software and tool charges arrive through several rails:

• ACH payments to a vendor, often monthly.
• Checks, still common for some annual contracts and local vendors.
• Annual invoices paid by bank transfer.
• Direct debits, set up once and rarely revisited. In the UK this is often the default for subscriptions.
• Card charges on a different card than the one a feed is connected to.

When the books are kept, all of these post to the ledger. They land in an expense account, against a vendor or a descriptor, on a date. That is enough for a review to group them and find the ones that repeat.

What the books add, and where they stop

No. The books show what was recorded, in the accounts and date range you include. If a payment was never entered or imported, or a card account is left out of the export, the review cannot find it. Tell clients the review reads payments recorded in their books, whatever way they were paid.

The ledger gives you one place to read payments across rails. That is the advantage. It is worth being precise about the edges too.

• Descriptors are only as clear as the bank or vendor made them. Some will need a question to the client.
• The books show payments, not seats, logins, or usage.

How each rail tends to look in a findings report

Different rails leave different marks in the ledger. A review that reads the books can flag each of them in plain language.

• ACH: the same vendor on a regular rhythm, with the amount on each date.
• Check: a payee and an amount, often once a year, with the date it cleared.
• Annual invoice: one larger charge, with the date it landed, so the next renewal is not a surprise.
• Direct debit: a descriptor that may not match the product name, flagged as worth a question.
• Charges on more than one card or account: the same vendor showing up in two places, flagged as a possible duplicate.

Each finding says what was paid and why it was flagged. Whether to keep, cancel, or consolidate is a conversation for the firm and the client.

Using both, not choosing one

No. A card program keeps doing its job on its own card: controls, receipts, and limits. A Software Spend Review reads the books, which include those card charges alongside ACH, checks, invoices, and direct debits. The two answer different questions, and the client does not need to adopt a new card or feed.

For a firm, the books are also where the work already sits. You need a transactions export or a connection to the ledger you already keep.

Getting the data in

The data can arrive two ways, and the findings engine is the same either way.

• CSV from any source: a books export, a bank export, or another ledger. The free audit takes one company's CSV with no card. How to shape it is in CSV-first Software Spend Review.
• Live connect: QuickBooks Online and Xero only, over OAuth. Anything else stays CSV. Google Workspace is not available.

For running this across many clients and delivering it under your firm name, read How to run a Software Spend Review across a client book and White-labeled Software Spend Review.

What this is not

• Not a card program, spend control, or bill pay tool.
• Not a claim that the books hold every payment. They hold what was recorded, in the accounts and dates you include.
• Not a seat, login, or usage review. A ledger records what was paid, not who logged in.
• Not a Google Workspace or identity integration. Google Workspace is not available.
• Not a savings promise. No averages, no percentages, no invented customers.
• Not SOC 2 certified. See /security and /dpa.

How to start

Pick one client who pays for software more than one way. Export a full year of transactions, including bank and card accounts, from whatever source you already use. Run the free audit at /sign-up?intent=free: one company, no card. Look for findings tied to ACH, checks, invoices, and direct debits, not only card lines.

If that is useful across more clients, the Firm overview and 14-day trial are on /for-bookkeepers. The Firm trial requires a card and covers your book of clients.