# 08 — Expenses & Payroll

The business explicitly requires tracking **branch rent** and **employee payroll**. Those
two, plus COGS, are what turn branch revenue into branch *profit* — the number the owner
actually manages by.

```
Branch Profit = Sales − COGS − Rent − Payroll − Other Opex
```

Everything in this document exists to make that line computable per branch, per month,
without a spreadsheet.

---

## 1. Expense model

One general structure covers rent, utilities, salaries and ad-hoc costs. Recurring items
are generated from a schedule rather than typed monthly.

### Expense category

| Field | Notes |
|---|---|
| `code`, `name_ar`, `name_en` | |
| `type` | `fixed` / `variable` |
| `is_cogs` | Excluded from opex; comes from inventory instead |
| `parent_category_id` | One level of nesting is enough |

Suggested chart:

```
RENT              — branch rent, deposits
PAYROLL           — salaries, overtime, bonuses, end-of-service
UTILITIES         — electricity, national grid, generator/ampere subscription, water, internet
FUEL_GAS          — cooking gas, generator fuel
MAINTENANCE       — equipment service, repairs, espresso machine servicing
SUPPLIES          — cleaning, disposables not tracked as inventory
TRANSPORT         — deliveries, staff transport
FEES_LICENCES     — municipal licences, permits, bank charges
MARKETING         — signage, printing, promotions
OTHER
```

> Note for Iraq: "electricity" realistically splits into **national grid** and
> **neighbourhood generator (ampere) subscription**. Keeping them as separate categories
> from the start avoids a messy re-categorisation later.

### Expense record

| Field | Notes |
|---|---|
| `id`, `branch_id`, `category_id` | Branch is mandatory — no unallocated expenses |
| `amount`, `currency`, `fx_rate?` | |
| `expense_date`, `period_start`, `period_end` | Period matters for rent and salaries |
| `payee_type` | `landlord` / `supplier` / `employee` / `utility` / `other` |
| `payee_id?` | |
| `description` | |
| `payment_method` | `cash_from_till` / `cash_from_safe` / `bank_transfer` / `card` / `unpaid` |
| `status` | `draft` / `pending_approval` / `approved` / `paid` / `rejected` |
| `attachment_ref?` | Photo of the receipt — one phone photo prevents most disputes |
| `recorded_by`, `approved_by`, `paid_at` | |
| `recurring_schedule_id?` | Set when generated from a schedule |

**Rules**
1. **Every expense belongs to exactly one branch.** Head-office costs are allocated to the
   Main Branch or to an explicit `HEAD_OFFICE` pseudo-branch — never left unassigned, or
   branch P&L stops adding up.
2. Expenses above a configurable threshold require approval before payment.
3. `cash_from_till` automatically creates a **pay-out** cash movement in the open shift
   (doc 06 §2). This link must be automatic — the most common cash variance cause is a
   manager paying a supplier from the till and telling nobody.
4. Expenses are immutable once `paid`. Corrections are reversing entries.

---

## 2. Recurring expenses — including branch rent

```
recurring_schedule {
  branch_id, category_id, payee_id?,
  amount, currency,
  frequency: monthly | quarterly | semi_annual | annual | every_n_days,
  interval_n?, anchor_day,
  start_date, end_date?,
  auto_generate_days_before: n,      // create the draft n days before due
  status: active | paused | ended
}
```

At `due_date − auto_generate_days_before` the system creates a **draft expense** and
notifies the Accountant and Branch Manager. It is never auto-paid.

### Branch rent specifically

The cafe rents its space inside each workspace building. Rent deserves a little more than a
generic recurring expense:

| Field | Notes |
|---|---|
| `branch_id` | |
| `landlord` | Name, contact, bank/payment details |
| `contract_ref`, `contract_start`, `contract_end` | |
| `amount`, `currency` | Commercial rents in Iraq are frequently quoted in **USD** — currency per contract is essential |
| `payment_frequency` | Monthly / quarterly / semi-annual / annual — advance payment of 6–12 months is common locally |
| `payment_in_advance` | Boolean; affects cash-flow forecasting and expense **accrual** |
| `deposit_amount`, `deposit_returned` | Tracked separately; a deposit is an asset, not an expense |
| `escalation_clause` | e.g. +10% annually — drives a renewal reminder with the new figure |
| `notice_period_days` | |
| `includes_utilities` | Avoids double-counting |

**Accrual rule.** If rent is paid annually in advance, the **cash movement** is one payment
but the **monthly P&L charge is 1/12**. Without this, one month shows a catastrophic loss
and eleven show inflated profit, making branch comparison worthless. The system stores both:

- `cash_expense` — when money actually left
- `accrued_expense` — the amount attributed to each reporting period

Branch P&L uses accrued. Cash-flow reports use cash.

### Rent alerts

| Alert | Timing |
|---|---|
| Rent due | 7 days before (configurable) |
| Contract expiring | 90 / 60 / 30 days before `contract_end` |
| Notice period deadline approaching | `contract_end − notice_period_days` |
| Escalation taking effect | 30 days before the new rate applies |

---

## 3. Employees

Distinct from **users** (doc 01). Every user *may* have an employee record; not every
employee needs a login (a cleaner does not).

| Field | Notes |
|---|---|
| `employee_number`, `full_name_ar`, `full_name_en` | |
| `branch_id` | Primary branch |
| `position` | Barista, Cashier, Supervisor, Manager, Cleaner, Driver, Storekeeper |
| `employment_type` | `full_time` / `part_time` / `hourly` / `temporary` |
| `hire_date`, `termination_date?`, `status` | |
| `base_salary`, `salary_currency`, `pay_frequency` | Monthly is the norm |
| `hourly_rate?` | For hourly staff |
| `allowances[]` | Transport, meal, phone, housing — recurring, named |
| `bank_details?` / `pays_in_cash` | Cash payment is common; needs a signed receipt |
| `national_id_ref`, `phone`, `emergency_contact` | |
| `user_id?` | Link to the login account |

---

## 4. Time & attendance (optional but high value)

If staff clock in on the branch terminal (PIN, same device as the POS), payroll stops being
a monthly argument and labour cost becomes a live number.

| Field | Notes |
|---|---|
| `employee_id`, `branch_id`, `date` | |
| `clock_in`, `clock_out`, `break_minutes` | |
| `scheduled_start`, `scheduled_end` | From the roster, if used |
| `hours_worked`, `overtime_hours` | Derived |
| `status` | `present` / `absent` / `late` / `leave` / `branch_closed` |
| `approved_by` | Manager approves the month before payroll runs |

**Live labour cost %** = payroll cost for the period ÷ sales for the period, per branch.
Together with COGS % it is the fastest read on whether a branch is being run well.

### Owner-declared closures and pay

Because the cafe trades every day and closures are declared ad hoc
([10 §3.1](10-cross-cutting-rules.md)):

| Rule | Reason |
|---|---|
| A closure day is recorded as `branch_closed` for every scheduled employee, **not** as absence. | Staff were not at fault and must not be marked absent by default. |
| `calendar_exception.is_paid_for_staff` decides whether the day is paid. **Default: paid.** | Monthly-salaried staff are unaffected; the flag matters for hourly staff. |
| Monthly-salaried employees are **not pro-rated down** for closures. | A closure is the employer's decision. |
| Hourly employees are paid only if `is_paid_for_staff` is true. | Explicit, and visible to the owner when declaring. |
| **Labour cost %** for a period divides by sales over **trading days only**. | Including a zero-sales closed day makes a well-run branch look overstaffed. |

---

## 5. Payroll

```
Draft ──▶ Calculated ──▶ Reviewed ──▶ Approved ──▶ Paid ──▶ Closed
```

### Payroll run

| Field | Notes |
|---|---|
| `period_start`, `period_end`, `branch_id?` | Per branch or consolidated |
| `status`, `calculated_at`, `approved_by`, `paid_at` | |
| `lines[]` | One per employee |

### Payroll line

```
gross =  base_salary (pro-rated for partial months)
       + overtime
       + allowances
       + bonuses / commission

deductions =  advances repaid            (سلفة)
            + absence / unpaid leave
            + staff consumption           (optional, from doc 07 §7)
            + fines / penalties
            + loan instalments
            + statutory deductions        (if applicable)

net = gross − deductions
```

Each line stores every component with its own reason and reference so an employee can be
shown exactly how the number was reached.

### Advances (سلفة) — model this properly

Salary advances are routine in Iraq and are the most common payroll dispute.

```
advance {
  employee_id, branch_id, amount, currency, date,
  reason, approved_by,
  repayment: single_deduction | instalments(n),
  outstanding_balance,
  status: outstanding | partially_repaid | repaid | written_off
}
```

**Rules**
- An advance paid from the till creates a cash pay-out movement (doc 06 §2).
- Outstanding advances are deducted automatically at the next payroll run.
- Advance balance per employee is visible to the Branch Manager and Owner at all times.
- Total outstanding advances per branch is a standing report — it is real money out the
  door that no other report shows.

### Payroll rules

1. **A payroll run is immutable once approved.** Corrections are adjustments in the next
   period, or a reversal + re-run while still `draft`.
2. **Payroll cost is attributed to the branch the employee worked at**, including days
   covering another branch, so labour cost % is accurate per branch.
3. **Payment confirmation is recorded per employee** (cash receipt signature reference or
   transfer reference). Cash payroll without a recorded confirmation is an open dispute.
4. **Payroll is visible only to Owner and Accountant.** Branch Managers see their branch's
   payroll *total* and labour %, not individual salaries.
5. End-of-service / severance accrual is out of scope for Phase 1 but the field exists.

---

## 6. Supplier payables

The mirror image of customer receivables (doc 05).

| Concept | Notes |
|---|---|
| `supplier_invoice` | Created from a goods receipt (doc 07 §5); references the PO and GRN |
| `payment_terms` | From the supplier record: `cash_on_delivery` / `net_days(n)` / `end_of_month` |
| `supplier_payment` | Allocated to one or more invoices, exactly like customer payments |
| `aging` | Same buckets: current / 1–30 / 31–60 / 61–90 / 90+ |

**Three-way match** before a supplier invoice is approved for payment:

```
Purchase Order  ↔  Goods Receipt  ↔  Supplier Invoice
   ordered            received          billed
```

Any mismatch is flagged and blocks payment until resolved. This is the single control that
stops a branch paying for goods it never received — the classic multi-branch leak when the
owner is in another city.

---

## 7. Cash-flow view

Because rent may be paid annually, salaries monthly and suppliers on net terms, the owner
needs a forward view separate from the P&L:

| Report | Content |
|---|---|
| **Upcoming obligations** | Next 30/60/90 days: rent due, payroll due, supplier invoices due, by branch |
| **Expected receipts** | Customer invoices due, by account and branch (doc 05) |
| **Net position by branch** | Expected in vs expected out |

This is where the receivables module (money in) and the payables/expense modules (money
out) finally meet, and it is the most valuable single screen for an owner running five
branches from one city.