Billing per-cashbook modules — design concepts

The idea: one table — rows are cashbooks, one column per module, toggle in the cell. Column footers show the count × price maths.

• 👍 Whole picture on one screen; scales to 300 cashbooks with search; the closest fit to "ugly but functional".
• 👎 Columns grow with each new module; per-module context (description, what it does) has nowhere to live.

Critic (1–5): Xero 4 · Hierarchy 4 · States 4

The idea: modules on the left (with counts and subtotals), the selected module's cashbook list with toggles on the right.

• 👍 Room for module descriptions and per-module bulk actions; cost summary reads like a bill.
• 👎 "Which modules does client X have?" needs a click per module — cashbook-first questions are second-class.

Critic (1–5): Xero 4 · Hierarchy 4 · States 4

The idea: cost summary cards up top, then one row per cashbook with module chips; a row expands to its module toggles.

• 👍 Best "explain my bill" hierarchy — cost first, detail on demand; rows stay compact at any module count.
• 👎 Toggling is two steps (expand, then switch); scanning who-has-what across 300 rows is chip-reading, not column-scanning.

Critic (1–5): Xero 4 · Hierarchy 4 · States 4

The idea: Concept A's matrix columns blended into the existing Dashboard CashBooks table — no new screen; search, tabs and pagination already exist there.

• 👍 Modules live where owners already work daily; zero new navigation; cost footer explains the bill in place.
• 👎 Owner-only columns mean two table variants (members see the standard table); column count grows with modules on an already-busy table.

Not a competing direction: the settled in-context enable path used by every concept — padlocked nav item, enable modal (owner / trial / member variants), locked direct-URL page, and the invoices tab "report generating" state.