Software Spend Review reads what was paid, not who logged in

If you keep the books for a client, you already see their software. It shows up as charges that repeat: a monthly line from the same vendor, an annual invoice that lands every spring, a direct debit with a descriptor the client owner may not recognize. A Software Spend Review does not go looking for new data. It organizes what was already paid into a findings report your firm can hand over.

This piece is about what that review reads and what it does not. The short version: it reads payments, not seats or logins. For the full firm workflow, read How to run a Software Spend Review across a client book. For the proof step on one export, read CSV-first Software Spend Review: prove it on one export before you connect live. For delivery under your firm name, read White-labeled Software Spend Review: the firm stays the brand and the client never logs in.

What the ledger can show, and what it cannot

No. A Software Spend Review reads transactions in the books, so it shows what was paid, not who logged in. It does not count seats, assigned licenses, logins, or usage, and it does not say a tool is idle. Seat and login reclaim needs identity data and app admin access, which is a different product.

A ledger records what was paid. That is a lot of useful information, and it has a clear edge.

What the transactions can show:

• Which vendors were paid, and how often.
• How much each charge was, and whether the amount changed over the date range.
• Charges that repeat on a monthly, quarterly, or annual rhythm.
• The same vendor showing up under more than one descriptor or more than one account.
• Renewal dates you can see from when the charges landed.

What the transactions cannot show:

• How many seats a client has, or how many are assigned.
• Who logged in, or when.
• Whether a tool is used every day or once a quarter.
• What other companies pay for the same tool.

A Software Spend Review stays with the payments, which is the part a bookkeeping firm already holds.

Why ACH, checks, invoices, and direct debits matter

Card-only tools see what hits their card. Small businesses also pay for software by ACH, check, annual invoice, and direct debit, and those payments still post to the books. A review that starts from the ledger reads them next to the card lines, so recurring software paid outside the card is part of the picture.

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

• ACH payments to a vendor.
• Checks, still common for some annual contracts.
• Annual invoices paid from the bank account.
• Direct debits set up years ago and never revisited.
• Card charges, on whichever card happened to be on file.

The books catch all of these because the books record payments, not payment rails. A review that starts from the ledger sees the ACH and the annual invoice next to the card line. This is not a replacement for a card program or a bill pay tool. It lists charges that already posted, including ones that never touched those tools.

What "charges that repeat" means in a findings report

Each finding says what was paid and why it was flagged. Typical findings are charges that repeat, vendors that look like the same product under different descriptors, amounts that moved between periods, annual charges with the date they landed, and unclear descriptors. Whether to keep, cancel, or consolidate is a conversation between the firm and the client.

The phrase is deliberate. A findings report should describe what the transactions show, in plain language the client owner can read without a glossary.

In practice, a finding looks like one of these:

• A vendor charged on a regular rhythm across the date range.
• Two or more vendors that look like the same product under different descriptors.
• A charge whose amount moved between periods.
• An annual charge, with the date it landed, so the next one is not a surprise.
• An odd or unclear descriptor that is worth a question to the client.

The report also does not promise a savings number. Results depend on the date range and which accounts are in the file. If you show /demo, the dollar figures there are sample figures on a made-up company. Use them to explain report shape, not as a forecast for any client.

Where CSV and live QuickBooks Online or Xero fit

No. Live connect to QuickBooks Online or Xero still reads accounting transactions, the same kind of data a transactions CSV carries. It does not read app admin consoles, identity providers, or login logs. Any other ledger or bank comes in as a CSV from any source, and Google Workspace is not available.

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

CSV comes first. The free CSV audit takes a transactions export from any source you already have: a books export, a bank export, or another ledger. It is not limited to QuickBooks Online or Xero files. No card. One company. How to shape that export, and why a thin file produces a thin report, is in CSV-first Software Spend Review.

Live connect comes later, if you want it. Live OAuth is QuickBooks Online and Xero only. Anything else stays a CSV. Google Workspace is not available, so do not promise it to a client or put it on a roadmap slide.

How a firm runs this across many clients, rather than one file at a time, is in How to run a Software Spend Review across a client book.

The leave-behind stays under your firm brand

The client does not log into ShadowLedger. The firm uploads the file or connects the books, then brands the report: your logo, prepared by your firm, prepared for that client. You deliver a PDF or a revocable share link.

That keeps the work where it already sits, with the firm the client hired. There is no new app for the client to adopt and no ShadowLedger account in the client's name. The full delivery model is in White-labeled Software Spend Review.

What this review is not

• Not unused-seat or unused-login reclaim. A ledger records what was paid, not who logged in.
• Not a usage monitor, and not a claim about which tools a team relies on.
• Not a card-only spend tool. ACH, checks, invoices, and direct debits are part of why the books matter.
• Not a single-company IT tool. It is built for a firm working across a book of clients.
• Not a Google Workspace or identity integration. Google Workspace is not available.
• Not a price benchmark or a renewal negotiation service.
• Not a savings promise. No averages, no percentages, no invented customers or testimonials.
• Not a substitute for SOC 2. We do not have SOC 2. Point to /security and /dpa when someone asks.

How to start

Pick one client where software and recurring tools show up in the books. Export a transactions CSV from whatever source you already use for that client. Run the free audit at /sign-up?intent=free. Read the findings as a list of what was paid and why each line was flagged. Put your logo on the report and hand it to the client as a PDF or share link.

If that review is useful on more than one client, the Firm overview and trial entry are on /for-bookkeepers. Keep the two paths separate: the free CSV audit is one company and no card; the Firm trial requires a card and is for the full book of clients.