Finance Foundation: the rulebook every report you publish inherits

Your team already has the messy-export and categorization-rules playbooks — the worked recipes for making one export trustworthy and writing the rules once. This module is the layer above the recipe. It’s where you master the three files every report inherits — how every number is classified, whether the data beneath it can be trusted, and who’s allowed to approve what — build them for your own books, and prove, against a real rubric, that you can.

It’s Module 1 of the certifiable Finance & Ops track, and it’s the one we leave open. Read it, do the assignment, and you’ll know exactly what the depth is worth before you put a team through the rest.

Every number your team publishes — every close, reconciliation, budget variance, cash model, and board pack — is a withdrawal from three accounts: how it’s classified, whether the data underneath is clean, and who signed off. Most teams never fund those accounts, so every report re-guesses the categories, trusts a total nobody checked, and ships on whoever happened to hit send. The foundation is the hour where you fund all three once, and it’s the highest-leverage hour in the whole track.

Why the foundation is the highest-leverage hour you’ll spend

Finance breaks quietly, one untraced number at a time. A category gets applied by feel, so the same vendor lands in “software” one month and “marketing” the next — and the trend line leadership is staring at is fiction nobody can see is wrong. A total gets trusted because it was in a spreadsheet, and the spreadsheet had three blank rows and a duplicate charge ID underneath it. A number goes to the board because it was due at 5pm, prepared and approved by the same tired person, with no second pair of eyes. None of these fail loudly. They fail in the audit, in the board meeting, in the FTA filing — long after the report shipped clean-looking.

Three documents fix all three. A categorization-rules.md decides how every number is classified — the vendor-to-category rules, the capex-versus-opex calls, the gray areas resolved once instead of re-litigated every close. A data-checklist.md decides whether you can trust the data — the profile you run before the first sum, and the rule that every figure traces back to a source row. A finance-controls.md decides who’s allowed to approve what — the separation of duties, the data that never leaves your workspace, and the verification gate a human owns. Build them once and every later task inherits them: you feed the rules into a close and the same vendor buckets the same way; you feed the checklist into a messy export and the dirt surfaces before the total; you feed the controls into any report and the sign-off line is never skipped because it’s due.

That’s why this is Module 1. Skip it and Claude just helps you publish miscategorized numbers, built on dirty data, with no sign-off, faster — which is worse, not better. Fund the three accounts first and every report downstream gets defensible for free.

The categorization rulebook — the judgment the recipe can’t teach

The playbook gives you the steps to write the rules. Mastery is the judgment inside them — the calls that separate a rulebook your reports inherit from a list of categories nobody applies the same way twice.

• A rule, or it’s re-guessed every month. A category applied by feel is the single most common way finance trend lines lie. The same AWS invoice is “hosting” in May and “software” in June, and now your software-spend chart shows a jump that never happened. For every recurring vendor and every account, write the rule down — this vendor → this category, always — and the gray areas with it. The whole point is that next month’s close, and the close after a teammate takes over, applies the identical rule without you in the room.
• Decide the gray areas once, out loud. Is a design subscription “software” or “marketing”? Is the contractor “payroll” or “professional services”? Is the new laptop capex or opex? These are the calls that get fudged differently every month when they live in someone’s head. Name them in the rulebook with the reasoning, so the answer is the same in the audit as it was in the close.
• Capex versus opex is the one auditors actually check. The classification the board and the auditor care about most is the one most often guessed. Decide your threshold and your rule here, in writing, not live when an auditor asks why a number landed where it did.
• The rulebook is what Claude inherits. This is the leverage: feed categorization-rules.md into any close, audit, or budget and Claude applies your rules, not its own guess — so you stop re-explaining “AWS is hosting, not software” in every single chat. One file, written once, makes every later report consistent with the last.

The data-trust checklist — profile before you trust a single total

The fastest way to publish a wrong number is to total a dirty file. A data-trust checklist is how you make an export trustworthy before you build anything on it — and the test of a good one is brutal: run it on a real export and it should catch the blank rows, the duplicate IDs, and the mismatched dates that a confident-looking total would have buried. A summary built on dirty data isn’t a fast summary; it’s a wrong one with a deadline attached.

A checklist that actually protects you is specific and run-first, not aspirational:

• Profile before the first sum. Row count, what each column means, blank rows, duplicate charge IDs, dates that aren’t in one format. Asking what’s wrong with this file is the highest-value ten minutes in any close, because every total you build inherits whatever you didn’t catch. The checklist is the thing you run before you trust the file, every time, on every export.
• Every figure traces to a source. This is the rule that lets you defend any number on the page: it traces back to a specific row in a specific source file. A number you can’t trace is a number you can’t defend — to an auditor, a board member, or the FTA — no matter how right it looks. Build the traceability in from the start; you can’t bolt it on after the report ships.
• Show the work, always. The discipline that keeps finance honest is asking Claude to show the formula or the steps it used — “I summed the Amount column for each Category, ignoring the 3 blank rows.” A total you can’t see the method behind is a black box, and a black box is exactly what you can’t put your name on. Spot-check one number by hand against the raw file; if it matches, you can trust the method on the rest.

Build the checklist from the exports you actually receive, not the clean ones you wish you got. The messy-export playbook walks the profiling; mastery is knowing that the checklist’s real job is the stop — refusing to total a file until it’s clean — because the cost of a wrong number isn’t zero, it’s the board meeting where you have to walk it back.

The controls doc — who’s allowed to approve what

Every team that touches money needs the same thing the auditors will ask for first: a clear line between the person who prepares a number and the person who approves anything that moves money. The craft of the controls doc is naming that line before you need it, because the failure mode — one tired person preparing and approving the same payment run at 5pm — never looks like a problem until it is one.

• Separation of duties is the load-bearing control. The preparer is never the approver for anything that moves money — a payment, a refund, a credit note, a journal entry. Claude can prepare all of them fast; a different human approves. This is the finance equivalent of a deal-desk gate: drafting is delegated, approval is not. Name who approves what, and the dollar thresholds, in the doc.
• Sensitive data stays in your workspace. Account numbers, payroll detail, customer PII, bank credentials — these live in a workspace you control, and Claude reads the local copy through the Desktop file pane, with each read approved in the “Ask permissions” prompt. Never paste an account number into a tool you don’t control. The controls doc names what’s sensitive so nobody has to guess in the moment.
• A human owns every number that goes out. Claude drafts the close, the variance note, the board figure — and a person verifies it, traces it, and decides it before it ships. The doc makes that non-negotiable and names whose signature it is. The point of asking Claude to show its work is precisely so a human can own the number rather than rubber-stamp it.

The controls doc is the one that feels like bureaucracy until the first time it saves you — the duplicate payment caught because a second person looked, the wrong number stopped before the board saw it. Keep it as one short, owned file, and every report inherits the sign-off discipline instead of improvising it under deadline.

The bilingual reporting standard — the part nobody else teaches

For a MENA team this isn’t a translation step bolted onto the board pack at the end. It’s a standard you set now, in the foundation, so the narratives you author in later modules inherit it. The rule is the same one the Sales and Marketing tracks teach — author, don’t translate — and for finance it has its own hard edges:

• The narrative is authored in Arabic, not translated. A leadership summary or a board narrative for an Arabic-reading owner reads untrustworthy the moment it reads translated — and in finance, where the whole product is trust in the numbers, that’s fatal. The M2 leadership summary and the M5 board narrative are written in Arabic from the figures, deciding deliberately where you sit between Modern Standard Arabic and a Gulf-natural register. M1’s job is to make that the standard, not an afterthought.
• Numbers, currency, and dates follow the convention. Numerals stay Western even in Arabic copy, currency is AED, and you decide up front whether dates are Gregorian only or Gregorian with Hijri — because a board pack that switches numeral systems mid-table reads amateur. Set it once in the controls doc.
• The layout mirrors; the figures don’t. Arabic tables and narrative run right-to-left, but the columns of numbers stay legible and aligned the way a finance reader expects. Getting RTL tables right is exactly the detail a translated-at-the-end pack botches.
• Same verification gate, both languages. An Arabic board figure clears the same trace-to-source and sign-off as the English. The failure mode is the approver who can’t read the Arabic narrative waving it through — so the gate is cleared by someone who actually reads it.

Done this way, the Arabic report is a first-class peer of the English. In this region that isn’t a nicety — it’s the credibility line with the people who sign off on the money.

Your assignment

Build the three foundation documents for one set of books — your own (recommended: the output is real infrastructure your team closes from) or the sample company Mizan, a GCC small-business bookkeeping SaaS whose own finance team runs throughout this track. Open the folder with your raw inputs — a billing or expense export, your chart of accounts, last month’s close — in Claude Desktop, approve each read in the “Ask permissions” prompt, and work in the chat — no terminal needed.

Module 1 deliverable — the foundation

1. categorization-rules.md  (one page)
   - the vendor → category rules for your recurring spend (the same vendor,
     the same bucket, every month)
   - the gray areas decided out loud, with the reasoning
   - the capex vs opex rule + threshold
   - what NEVER gets auto-categorized without a human (the exceptions)

2. data-checklist.md  (one page)
   - the profile you run BEFORE the first total: row count, column meanings,
     blank rows, duplicate IDs, mismatched dates
   - the trace-to-source rule: every figure points back to a source row
   - "show the work" — Claude states the formula/steps for every total
   - the spot-check habit: one number verified by hand against the raw file

3. finance-controls.md  (one page)
   - separation of duties: who PREPARES vs who APPROVES, and the thresholds
   - what's sensitive and stays in the workspace (account #s, payroll, PII)
   - the verification gate: a human owns every number that ships
   - the bilingual reporting standard (Western numerals, AED, dates, RTL,
     authored-not-translated)

Bilingual teams: confirm the reporting standard with a 3-line Arabic sample —
a number explained, authored not translated, to prove the register.

The Foundation toolkit gives you a fill-in template for each of these and the prompts that build them, so you’re filling in structure, not staring at a blank page.

How it’s graded — the rubric

This is the part the free playbook doesn’t have, and the part that makes the credential mean something. Your three files are scored against five criteria. Each is meets / nearly / not yet — and “nearly” on any one is a revise, not a pass.

Foundation rubric

1. The rules are unambiguous   The same vendor lands in the same bucket every
                               month. Gray areas are decided in writing, not
                               left to feel. Capex/opex has a stated rule.
2. The data is trustworthy     The checklist actually catches blank rows, dup
                               IDs, and mismatched dates BEFORE any total.
                               Every figure traces to a source row.
3. The math is shown           No total is a black box. Claude states the
                               formula/steps; one number is spot-checked by
                               hand. A stranger could re-run it.
4. The controls are real       Preparer ≠ approver is named, with thresholds.
                               Sensitive data is named and kept in the
                               workspace. A human owns every number out.
5. The bilingual standard      Western numerals, AED, RTL, and dates are set;
   is right                    narratives will be authored in Arabic, not
                               translated. (Bilingual teams.)

The discipline is deliberately what a senior controller would demand: a foundation that’s vague, untraceable, or unsigned fails quietly in the audit, so it has to be caught here.

The bar, shown — a worked model answer (Mizan)

You don’t have to guess what “meets” looks like. Here’s a passing excerpt for the sample company — yours doesn’t need to look like this, it needs to clear the same bar.

categorization-rules.md — Mizan (excerpt)

Recurring vendors → category (always the same bucket)
  AWS                  → Hosting & infra      (never "software")
  Bayzat (payroll/HR)  → Payroll              (the tool, not the wages line)
  Slack, Notion        → Software & tools
  Meta / Google Ads    → Marketing
  WeWork               → Office & admin

Gray areas, decided once
  - Design subscriptions (Figma) → Software & tools, NOT Marketing.
    Reason: it's a tool the product team uses, not campaign spend.
  - Contractors on monthly retainer → Professional services, NOT Payroll.
    Reason: Payroll = employees on the FTA-registered payroll only.

Capex vs opex
  Rule: capitalize hardware/assets ≥ AED 5,000 with >1yr useful life;
  everything else is opex. A laptop at AED 4,200 is opex.

Never auto-categorized without a human
  - any new vendor seen for the first time
  - anything that could be capex (crosses the threshold)

data-checklist.md — Mizan (excerpt)

Run BEFORE any total (every export, every time)
  [ ] row count stated         (May: 1,248 rows)
  [ ] every column's meaning named
  [ ] blank rows flagged        (May: 3 — excluded, noted)
  [ ] duplicate charge IDs      (May: 2 — investigated before summing)
  [ ] dates in ONE format       (May: 14 as MM/DD → normalized to YYYY-MM-DD)

The trace-to-source rule
  Every figure in any report points back to: source file + the rows summed.
  A number that can't name its source rows does not ship.

Show the work
  Every total comes with its method in one line:
  "Summed Amount by Category, excluding the 3 blank rows."  ← re-runnable

Spot-check
  Pick ONE category total each close, re-add it by hand from the raw file.
  Matches → trust the method on the rest. Doesn't → stop, the file is dirty.

finance-controls.md — Mizan (excerpt)

Separation of duties (preparer ≠ approver)
  Prepares: the analyst (or Claude, drafting).  Approves: the controller.
  - Payments / refunds / credit notes      → controller approves, any amount
  - Journal entries > AED 10,000           → controller approves
  - The board figure / FTA filing          → founder + controller sign

Sensitive — stays in the Mizan finance workspace (never pasted out)
  customer account numbers · payroll detail · bank credentials · contracts
  Claude reads the LOCAL copy via the file pane; each read approved in the
  "Ask permissions" prompt.

A human owns every number out
  Claude drafts; a person traces it to source and signs. No rubber-stamping.

Bilingual reporting standard
  Numerals Western · currency AED · dates Gregorian · tables RTL.
  Leadership summary (M2) + board narrative (M5) authored in Arabic, not
  translated. Arabic figures clear the same trace-to-source + sign-off gate.

What you’ve proven — and what’s next

Clear the rubric and you’ve done something the free path can’t certify: you’ve built a real, professional-grade foundation and demonstrated the judgment behind it. That’s the Foundation stage of “Certified Finance & Ops with Claude.”

From here the track turns the foundation into a working finance function, each module assessed the same way:

• Module 2 — the monthly report: the repeatable close-and-report cycle that turns these three files into a reconciliation, a spend audit, and a leadership summary leadership actually reads — every number traced, in English and Arabic.
• Module 3 — plan & forecast, Module 4 — the cash levers, Module 5 — the close & the board, then the capstone — one company’s month closed and reported end to end, graded into the certificate.

First, make what you built reusable. Grab the Foundation toolkit — the finance CLAUDE.md and the three templates that turn the documents you just wrote into files your whole team installs and inherits. And if you’re rolling this across a team, the operating guide is the data, controls, and sign-off layer that goes underneath all of it.