How to Build a Marketing Expense Ledger That Actually Connects to Case Outcomes

A marketing expense ledger that just tracks what you spent is an accounting document. A marketing expense ledger that connects each dollar to the cases it produced is a management tool — one that drives better vendor decisions, more accurate ROI calculations, and more credible conversations with managing partners.

Most PI firms have the first kind. This guide explains how to build the second kind.

What a Standard Marketing Expense Ledger Gets Wrong

The typical marketing expense ledger in a PI firm looks like an accounting chart of accounts: vendor name, invoice date, invoice amount, payment date, category. That's useful for reconciliation, but it answers none of the questions that matter for marketing decisions.

Specifically, it can't answer:

• What did this $45,000 with Vendor C actually produce in signed cases?
• What is our cost per signed case for each vendor this month vs. last month?
• Which vendors are producing cases that match our target case profile?
• How does this month's spend track against our expected case pipeline value?

The fix isn't to replace the accounting ledger — it's to build a parallel marketing intelligence ledger that enriches spend data with outcome data.

The Structure of a Connected Marketing Expense Ledger

A marketing expense ledger that connects to case outcomes has two interlocking tables: the expense table and the outcome table. They share a common key — the vendor/period combination — that allows you to join them.

Table 1 — The Expense Table

This is the enhanced version of your existing ledger. For each vendor invoice or expense item, capture:

• Vendor name (standardized, not however it appears on the invoice)
• Vendor category (pay-per-lead, digital, TV/radio, referral, managed search, etc.)
• Billing period (the month the spend corresponds to, not the invoice date)
• Invoice amount
• Any adjustments or credits applied
• Net amount paid
• Payment date
• Budgeted amount for this vendor this month
• Budget variance
• Contract type (fixed, variable, hybrid)
• Whether the invoice was reconciled against lead delivery records

The additions — billing period (not invoice date), budget fields, and reconciliation status — are what separate this from an accounting-only ledger.

Table 2 — The Outcome Table

For each vendor and each billing period, record what the spend produced:

• Vendor name (matching exactly to Table 1)
• Billing period (matching exactly to Table 1)
• Leads received from this vendor this period
• Leads that resulted in a completed intake
• Leads that resulted in a signed case
• Cases signed: case type breakdown (auto, slip and fall, mass tort, etc.)
• Cost per signed case (automatically calculated: expense / signed cases)
• Projected average net fee based on case type mix
• Projected pipeline value from this spend

When you join these two tables, every expense entry has a corresponding case outcome — and every case outcome has a corresponding expense. That connection is the foundation of a functioning marketing intelligence ledger.

Building the Connection: How Expense Entries Become Case Records

The mechanical challenge in building this ledger is ensuring that every case in your intake system is connected back to a vendor and a billing period. That connection requires two things:

Standardized Vendor Naming

Your intake system probably has vendor names entered by whoever processed the lead. That means the same vendor might appear as “Mass Tort Hub,” “MTH,” “Mass Tort Hub LLC,” or “mass tort hub” depending on who typed it. When you try to join that data to your expense ledger, the join fails.

Solve this with a vendor lookup table — a master list of approved vendor names that intake staff select from a dropdown rather than typing freeform. If your intake system supports dropdown fields, configure them. If not, build a manual normalization step into your monthly reconciliation.

Billing Period Alignment

Lead delivery and billing don't always align to the same calendar month. A vendor might deliver leads throughout March but invoice on April 1. Or a TV campaign might run in March but the agency invoices in arrears.

For the expense ledger, assign each expense to the month the leads were delivered — not the month the invoice was received or paid. This keeps your cost per case calculations accurate even when billing timing is irregular.

Adding the Settlement Layer Over Time

The most powerful version of a connected marketing expense ledger includes a third table: settled case outcomes. This is where the true financial intelligence lives.

Table 3 — The Settlement Attribution Table

For each case that settles, record:

• Case ID
• Originating vendor (from intake record)
• Billing period when the lead arrived
• Date case was signed
• Date case settled
• Gross settlement amount
• Net attorney fee
• Case type
• Marketing cost attributed to this case
• Case-level ROI: net fee / attributed marketing cost

Attributing a specific marketing cost to an individual case requires amortizing the vendor's monthly spend across the cases they produced that month. If Vendor A spent $40,000 in March and produced 20 signed cases, each case carries an attributed cost of $2,000.

This is a simplified amortization, but it's workable — and it gives you a case-level ROI metric that rolls up cleanly to the vendor level.

The Reconciliation Workflow

A connected marketing expense ledger is only useful if it's current. Here's a monthly reconciliation workflow that keeps it maintained without becoming a full-time job:

1. By the 5th of the month: All invoices from the previous month are entered in the expense table. Each is assigned to its billing period (not invoice date).
2. By the 7th: Variable-rate invoices (pay-per-lead, pay-per-call) are reconciled against intake records. Discrepancies are flagged for vendor follow-up before payment.
3. By the 10th:The outcome table is updated with the previous month's case data. Cases signed in the prior month are counted, categorized by type, and linked to their originating vendor.
4. By the 15th: Any cases that settled in the prior month are recorded in the settlement attribution table with their settlement amounts.
5. Monthly review: Cost per case by vendor is calculated and compared against the prior month and prior year. Significant variances trigger a review of the underlying data before any decisions are made.

What This Ledger Enables

A connected marketing expense ledger changes the nature of your decision-making conversations:

• Vendor renewal negotiations:Instead of negotiating based on a vendor's performance claims, you negotiate based on your actual cost per case history, your settlement data, and the gap between their pricing and their ROI.
• Budget reallocation:When a vendor's cost per case is trending upward for three consecutive months, you have documented evidence to justify reducing their budget before waiting for the situation to get worse.
• Partner reporting:When a managing partner asks how the firm's marketing investment is performing, the answer is a number with a methodology behind it — not an estimate.
• New vendor evaluation: When you add a new vendor, you have a clear framework for evaluating their performance: cost per case against your established average, case type mix against your target, and conversion rate against your intake benchmarks.

A Note on Tools

You can build a working version of this ledger in a well-structured spreadsheet. The core logic — two to three joined tables, consistent vendor naming, billing period alignment — doesn't require dedicated software.

The limitation of a spreadsheet version is maintenance load. As vendor count and case volume increase, manual reconciliation consumes more time and introduces more error risk. A purpose-built revenue intelligence platform automates the joins, maintains the vendor naming conventions, and keeps the tables current without manual data entry — but the underlying structure is the same whether you're working in a spreadsheet or a dedicated system.

Start with the structure. The tooling decision can follow once you understand what the data needs to do.