LEXTIME/i — Law-Firm Time, Billing & Trust Accounting

LEXTIME/i is a law-firm practice-management application: clients and their legal matters, timekeeper time and expense capture with a daily edit, a billing run that sweeps unbilled work-in-progress (WIP) into invoices — applying a per-matter write-down to fees, billing expenses at cost, applying client trust (IOLTA) funds, and posting the remainder to accounts receivable — and a monthly close (AR aging, trust reconciliation, a balanced GL feed and a trial balance). The whole app is written in RPG (fixed and free form), ILE COBOL, CL and DDS over DB2 for i physical/logical files, with one SQL table for the GL distribution. The strict invariant it enforces everywhere is that a client's trust balance may never go negative. This manual is the reference for the operator who runs the three job cycles and the two online inquiry screens, and for the developer maintaining the application. It is grounded entirely in the committed source (legal-app/src/sources.mjs, src/seed.mjs, the DDS/RPG/COBOL/CL members it loads into library LEXTIME, FINDINGS.md, and the test/lt_build.mjs / lt_daily.mjs / lt_cycles.mjs drivers).

A. Overview & Architecture ↑ top

A.1 What it does

LEXTIME/i tracks the full life of billable legal work, from a timekeeper's logged hour to cash and the general ledger:

• Matters & reference data — clients, timekeepers (partners / associates / paralegals, each with their own bill rate) and matters (legal engagements, each with a client and a write-down percentage) are the master data every cycle reads.
• Daily time & expense capture — raw time and expense cards land as entered rows; a daily edit validates each one (matter exists and is active, timekeeper exists and is active, hours within a 24-hour ceiling and positive) and either promotes it to validated WIP with a computed fee, or rejects it with a reason code.
• Billing — the billing run sweeps each active matter's validated WIP into an invoice: time fees carry the matter's write-down (a realization discount), expenses bill at cost, then available client trust funds are applied and whatever remains posts to AR.
• Trust (IOLTA) accounting — client funds are held per client and drawn down by the billing run; the balance may never go negative, and a monthly reconciliation re-derives it independently from the ledger.
• Monthly close — AR aging by bucket, trust reconciliation, a balanced double-entry GL distribution into a SQL feed, and a trial balance that proves every figure reconciles.

A.2 The WIP-to-cash pipeline

The application is a single, auditable pipeline. A timekeeper's hour becomes cash and a GL entry in a fixed sequence, each step validated and each money movement journaled:

  time/expense  --edit-->  validated WIP  --bill-->  invoice  --trust-->  AR  --close-->  GL feed
   (E rows)               (V rows, rated)          (LTBILH/D)  (applied)  (LTAR)  (LTGLFEED)

The billing model is deliberately hand-derivable — every figure below is stated in the test oracles to the exact cent:

time fee (line)    = HOURS x BILLRATE           (the timekeeper's own rate)
  time fees (matter) = SUM(time fee lines) over the matter's 'V' time WIP
  write-down amount  = time fees x WDPCT          (matter's write-down %, 7P4)
  billed fees        = time fees - write-down amount
  expenses (matter)  = SUM(expense 'V' WIP)       (AT COST, no write-down)
  invoice total      = billed fees + expenses
  trust applied      = MIN(invoice total, available trust balance)
  AR posted          = invoice total - trust applied
  trust balance after= trust balance before - trust applied   (must stay >= 0)

The write-down is genuinely per-matter, not a hidden floor: a matter with WDPCT=0.0000 bills billed-fees = time-fees exactly. Trust application is optional: a client with no trust account bills the full invoice straight to AR. And trust is capped at the balance, not the invoice, so a client whose funds fall short posts the remainder to AR while the balance lands at exactly zero — never negative.

A.3 Component & flow

  REFERENCE / SEED       ONLINE                 BATCH (three cycles)
  ----------------       ------                 --------------------
  LTREFLD (clients,      LTMENU (5250)          LXDAILY   -> LTTIMLD  (raw capture)
    timekeepers,           opt 1 -> LTMTRIQ       (daily)     LTWIPED  (edit/validate)
    matters)               opt 2 -> LTWIPIQ                   LTWIPRP  (reject report)
  LTTRDEP (trust                                LXBILL    -> LTBILL   (WIP -> invoice)
    deposits)                                     (billing)   LTBILPRT (invoice register)
  LTTIMLD (raw time                                          LTGLRPT  (trial balance, COBOL)
    & expense cards)                            LXMONTH   -> LTARAGE  (AR aging)
                                                  (monthly)   LTTRREC  (trust reconciliation)
                          \                    /              LTGLDST  (GL feed, SQLRPGLE)
                           \                  /               LTGLRPT  (trial balance, COBOL)
                            v                v
     library LEXTIME: LTMATR/LTTIME/LTEXP/LTTRUST/LTTRLDG/LTBILH/LTBILD/LTAR + logicals
            |
            v
     LTGLFEED (SQL GL distribution table) <-- the monthly close posts balanced DR/CR pairs

A single event — say a day's billing — flows: the daily cycle has already left validated ('V') WIP on LTTIME/LTEXP → LTBILL scans the active matters, sums each matter's WIP, computes the invoice, applies trust from LTTRUST (writing an APP row to the trust ledger and reducing the balance), posts the AR remainder to LTAR, writes the invoice header/detail (LTBILH/LTBILD) and flips each swept WIP row to billed ('B').

A.4 Object inventory

The full catalogue is 10 physical files + 5 logical files, 1 SQL table, 3 display files and 1 printer file, driven by 13 RPG programs, 1 ILE COBOL program and 4 CL programs. Sections D and F expand each. Everything lives in library LEXTIME.

B. Online Transactions & Screens ↑ top

B.1 The command/entry line

LEXTIME/i has no CICS transaction identifiers. On IBM i, each program is reached by name from a 5250 command-entry line (or a JOBQ/scheduler for the batch cycles). The operator equivalent of "type a transid and Enter" is "type a CALL command and Enter". Before invoking anything, the job's library list must include LEXTIME — the tested jobs run with LIBL = QSYS QGPL LEXTIME QTEMP and CURLIB = LEXTIME (each CL cycle also issues its own ADDLIBLE LIB(LEXTIME) defensively).

The batch cycles take no CALL parameters and drive fixed processing dates baked into the programs (e.g. the billing run dates invoices 20260814, the AR-aging report ages as of 20260913), matching the app's hand-checkable test convention. Only LTMENU, LTMTRIQ and LTWIPIQ are interactive; the batch programs run to completion and DSPLY a one-line result per step to the job log.

B.2 The main menu & inquiry screens

Three display files drive the online surface: LTMENUD (the menu), LTMATRD (a plain matter-inquiry screen) and LTWIPD (a WIP subfile). All are read-only inquiry screens — LEXTIME/i does not capture time or post payments interactively; capture is the batch daily cycle's job (section C).

The main menu (LTMENU / LTMENUD)

Key 1 to CALL 'LTMTRIQ', 2 to CALL 'LTWIPIQ'; any other non-blank option redisplays with Invalid option. in the message line. F3 (DDS CA03 → indicator *IN03) exits.

Matter inquiry (LTMTRIQ / LTMATRD)

A plain (non-subfile) screen. Key a matter number; the program CHAINs LTMATR, shows the client name (from LTCLNT), the description, the write-down policy and status, and a derived unbilled WIP total — the sum of validated ('V') time fees plus validated expenses for that matter, read over the status logicals LTTIMLF/LTEXPLF on the 'V'+matter key. Note this WIP figure is the raw pre-write-down value (write-down is a billing-time discount, not part of what sits in WIP).

An unknown matter blanks the fields and shows Matter not found.

WIP subfile inquiry (LTWIPIQ / LTWIPD)

The app's subfile screen (DDS record WSFL under control record WCTL, SFLPAG(5) per page / SFLSIZ(20), ROLLUP/ROLLDOWN paging). Key a matter number; the program clears and reloads the subfile with one row per validated ('V') WIP entry — time lines (with the timekeeper name, hours and fee) then expense lines (description and amount) — and totals the time fees and expenses in the header. Because it reads the same 'V' status key the billing run uses, the subfile always reflects the current unbilled WIP, never a stale billed line.

Subfile columns (WSFL)

B.3 Controls & audit workflow (no four-eyes maker–checker)

Honest statement: LEXTIME/i does not model a true four-eyes maker–checker / separate-authorization workflow. There is no "one user enters time, a second user approves the bill" gate in the code: the daily edit validates cards automatically, and the billing run sweeps and bills WIP in one flow. The manual documents the control model the application does have:

• Two durable ledgers. Every trust movement is written to LTTRLDG (DEP deposit / APP application) and every AR posting to LTAR (INVC), each keyed on a stable business key so a re-run regenerates the same key and is refused rather than double-posting.
• Running balance vs. re-derived balance. LTTRUST.TRBAL is the quickly-readable running trust balance the billing run checks; the monthly LTTRREC independently re-sums the ledger (DEP adds, APP subtracts) and asserts the two agree to the cent — the audit proof that the balance was only ever moved by a properly ledgered posting.
• Status gating. The daily edit gates capture by matter and timekeeper state: an unknown or closed matter, or an unknown or terminated timekeeper, is rejected (reason codes E1–E5, section F.5). The billing run bills only validated ('V') WIP and flips it to 'B', so nothing is billed twice.
• The strict trust invariant. Trust applied is capped at MIN(invoice total, balance) and clamped non-negative, enforced at the one posting site in LTBILL, so the balance can never go below zero — a client-funds liability invariant re-verified monthly by LTTRREC.

In sum, the control posture is dual-ledger audit + running/re-derived balance reconciliation + status gating + a strict never-negative trust invariant, all in the data-and-batch layer, rather than a segregation-of-duties approval workflow.

C. Batch Jobs & the Periodic Cycle ↑ top

LEXTIME/i runs as three CL-driven cycles, each doing real, distinct work: a daily cycle (LXDAILY — time/expense capture + edit + reject report), a billing cycle (LXBILL — WIP→invoice, trust application, AR posting, register print, trial balance) and a monthly cycle (LXMONTH — AR aging, trust reconciliation, GL distribution, trial balance). Each CL is a bare sequence of CALL PGM(...) steps with a closing SNDPGMMSG banner; a scheduled submission is a bare SBMJOB CMD(CALL ...). Before the very first run, LTSETUP creates every object and compiles every program, and the seed programs (LTREFLD, LTTRDEP) load reference data and initial trust deposits.

-- one-time build of the whole application
CALL PGM(LEXTIME/LTSETUP)
CALL PGM(LEXTIME/LTREFLD)      clients, timekeepers, matters
CALL PGM(LEXTIME/LTTRDEP)      initial trust deposits (C00001 1000.00, C00002 300.00)

-- then the three cycles, in order
SBMJOB CMD(CALL PGM(LEXTIME/LXDAILY)) JOB(LXDAILY)
SBMJOB CMD(CALL PGM(LEXTIME/LXBILL))  JOB(LXBILL)
SBMJOB CMD(CALL PGM(LEXTIME/LXMONTH)) JOB(LXMONTH)

C.1 Full batch program set

C.2 Daily / billing / monthly detail

Daily — LXDAILY

LTTIMLD writes 10 raw time cards and 5 raw expense cards (all status 'E', unrated), including deliberate bad cards. LTWIPED then walks every 'E' row: for a time entry it CHAINs the matter (E1 if missing, E2 if not active), then the timekeeper (E5 if missing or terminated, else defaulting TRATE from BILLRATE), then checks hours (E3 over the 24-hour ceiling, E4 zero-or-negative); a clean entry is rated TFEE = THOURS × TRATE (half-adjusted to exact cents) and flipped to 'V'. Expenses take the same E1/E2 matter checks (E4/E5 don't apply) and flip to 'V' at cost. LTWIPRP reports the rejects over the status logicals.

Expected DSPLY:
  LTTIMLD TCARDS=10 XCARDS=5 SKIP=0
  LTWIPED TOK=5 TREJ=5 XOK=3 XREJ=2   5 clean time (fees 7337.50), 3 clean exp (510.50)
  LTWIPRP TREJ=5 E1=1 E2=1 E3=1
  LTWIPRP E4=1 E5=1 XREJ=2            one reject of each kind, both bad expenses

Billing — LXBILL

LTBILL scans all active matters; for each one carrying validated WIP it sums time fees and expenses, applies the matter write-down to fees only, computes the invoice total, applies MIN(total, trust balance) from LTTRUST (writing an APP ledger row and reducing the balance, never below zero), posts the AR remainder to LTAR, writes the invoice header and detail lines (one summarised T line per timekeeper, the X expense lines, then an informational W write-down line when the write-down is positive), and flips each swept WIP row to 'B'. Matters bill in matter-number order, so a client's earlier matter drains the trust first. LTBILPRT prints the register; LTGLRPT proves the trial balance.

Expected DSPLY / hand-derived invoices:
  LTBILL BILLED=4 SKIP=1              M00005 closed, no WIP -> skipped
  M00001  fees 4900.00  wd 490.00 (10%)  billed 4410.00  exp 250.00  TOTAL 4660.00
          trust MIN(4660,1000)=1000.00   AR 3660.00   balance after 0.00
  M00002  fees 437.50   wd 0.00          billed 437.50   exp 0.00     TOTAL 437.50
          trust MIN(437.50,0)=0.00 (drained by M00001)  AR 437.50 in full
  M00003  fees 1100.00  wd 55.00  (5%)   billed 1045.00  exp 85.50    TOTAL 1130.50
          trust MIN(1130.50,300)=300.00 (partial, capped at balance)  AR 830.50
  M00004  fees 900.00   wd 0.00          billed 900.00   exp 175.00   TOTAL 1075.00
          no trust account -> trust 0.00  AR 1075.00 in full
  TOTALS  billed 7303.00  trust applied 1300.00  AR posted 6003.00  (7303 - 1300 = 6003)

Monthly — LXMONTH

LTARAGE buckets each open invoice's outstanding balance (BARAMT - BPAIDAMT) by age from BILDT to a fixed as-of date 20260913, using a 30-day-month julian approximation (CURRENT 0–30, B31 31–60, B61 61–90, B90 over 90). LTTRREC re-sums the trust ledger per client and asserts it matches TRBAL with zero breaks and zero negatives. LTGLDST sums the invoice headers and posts balanced DR/CR pairs into LTGLFEED. LTGLRPT closes with the trial balance.

Expected DSPLY (with one injected 74-day-old 500.00 invoice for aging):
  LTARAGE INVS=5  CUR=6003.00 ...      the 4 real invoices are exactly on the 30-day edge
  LTARAGE ... B61=500.00 ...           the injected aged invoice
  LTTRREC CLIENTS=2 BREAKS=0 NEG=0
  LTTRREC TOTAL TRUST LIABILITY=0.00   both accounts fully drained, strict zero
  LTGLRPT TOTDIFF 0.00 / ARDIFF 0.00   every figure reconciles

C.3 Ordering & dependencies

• Setup + seeds first. LTSETUP then LTREFLD (masters) then LTTRDEP (trust) must run before any cycle; the billing run has nothing to apply trust against otherwise.
• DAILY before BILLING. The billing run consumes only validated ('V') WIP; LTWIPED is what produces it. Run the daily cycle, then bill.
• BILLING before MONTHLY. AR aging, trust reconciliation and the GL distribution all read the invoices the billing run wrote; the monthly close must run last.
• Within a cycle the order is fixed by the CL: capture→edit→report (daily); bill→print→trial-balance (billing); age→reconcile→distribute→trial-balance (monthly).
• Matter-number order matters for trust. Because LTBILL bills in MTNO order, a client's lower-numbered matter drains the shared trust balance before a higher-numbered one — the reason C00001's M00001 takes the full 1000.00 and M00002 gets 0.00.

D. Data Files (data dictionary) ↑ top

All files are in library LEXTIME, described in DDS in src/sources.mjs. Dates are stored as signed numeric YYYYMMDD (8S 0); money is packed 11P 2; rates and the write-down percentage are packed 7P 4 (so 450.0000 is a rate and 0.1000 is 10%). Business keys are the letter+5-digit spine convention (C00001, T00001, M00001).

LTCLNT — Client master (key CLNO, UNIQUE)

LTTKPR — Timekeeper master (key TKNO, UNIQUE)

Seeded set: T00001 partner 450.0000/180.0000, T00002 associate 275.0000/110.0000, T00003 paralegal 125.0000/45.0000, T00004 associate 300.0000/120.0000 (terminated).

LTMATR — Matter master (key MTNO, UNIQUE)

Seeded: M00001→C00001 (10%), M00002→C00001 (0%), M00003→C00002 (5%), M00004→C00003 (0%), M00005→C00002 (closed).

LTTIME — Time entry / WIP (key TENTNO, UNIQUE)

LTEXP — Expense entry / WIP (key XENTNO, UNIQUE)

LTTRUST — Trust (IOLTA) account (key CLNO, UNIQUE)

LTTRLDG — Trust ledger (key TRSEQ, UNIQUE)

LTBILH — Invoice header (key BILNO, UNIQUE)

LTBILD — Invoice detail lines (key BILNO, LSEQ, UNIQUE)

LTAR — AR ledger (key ARSEQ, UNIQUE)

LTGLFEED — GL distribution (SQL table, PK GLSEQ)

Logical files & relationships

• LTMATLF — matters keyed CLNO, MTNO (client access path over LTMATR).
• LTTIMLF / LTEXPLF — time/expense keyed TSTAT/XSTAT then MTNO (WIP-status access path), so a status range read avoids a full-file scan.
• LTTRLLF — trust ledger keyed CLNO (client access path over LTTRLDG).
• LTBILLF — invoices keyed CLNO, BSTAT, BILNO (client AR access path over LTBILH).
• LTMATR.CLNO → LTCLNT.CLNO; LTTIME.TKNO → LTTKPR.TKNO; LTTIME/LTEXP.MTNO → LTMATR.MTNO; LTTRUST/LTTRLDG.CLNO → LTCLNT.CLNO; LTBILH.MTNO/CLNO reference the matter/client; LTBILD.BILNO → LTBILH.BILNO.

E. Operations Runbook ↑ top

E.1 Day-in-the-life

1. Confirm the job's library list includes LEXTIME (each CL also issues its own ADDLIBLE).
2. First-time only: build the app and seed it — CALL LEXTIME/LTSETUP, then CALL LEXTIME/LTREFLD (masters), then CALL LEXTIME/LTTRDEP (trust deposits).
3. Run the daily capture/edit cycle: SBMJOB CMD(CALL PGM(LEXTIME/LXDAILY)).
4. Post-check the daily run (see below), then handle any interactive inquiries through CALL LEXTIME/LTMENU.

Post-checks after the daily cycle:

• LTTIMLD TCARDS=10 XCARDS=5 SKIP=0 on the first load (a re-run shows TCARDS=0 XCARDS=0 SKIP=15 — the sequential-counter guard refusing every card again).
• LTWIPED TOK=5 TREJ=5 XOK=3 XREJ=2; validated time fees total 7337.50 and validated expenses 510.50.
• LTWIPRP breaks the rejects out as E1=1 E2=1 E3=1 E4=1 E5=1 (time) and XREJ=2 (expense), proving the status logicals are genuine keyed access paths.
• Every rejected entry carries no rate and no fee; every validated entry carries its computed fee.

E.2 Billing & month-end close

1. Confirm the daily cycle has left validated ('V') WIP on file.
2. Run the billing cycle: SBMJOB CMD(CALL PGM(LEXTIME/LXBILL)). Confirm LTBILL BILLED=4 SKIP=1 and review the spooled invoice register (INVS=4 BILLED=7303).
3. Reconcile the billing figures (the same ones the volume simulation checks to the cent against an independent JS oracle):

SELECT MTNO, BFEES, BWDOWN, BEXP, BTOT, BTRUST, BARAMT
  FROM LEXTIME/LTBILH ORDER BY MTNO;

• Invoice totals — M00001 4660.00, M00002 437.50, M00003 1130.50, M00004 1075.00; period billed 7303.00.
• Trust applied — M00001 1000.00 (full balance), M00002 0.00 (drained), M00003 300.00 (partial), M00004 0.00 (no account); total 1300.00. Both trust accounts end at exactly 0.00, never negative.
• AR posted — 3660.00 + 437.50 + 830.50 + 1075.00 = 6003.00, and billed − trust = AR exactly (7303.00 − 1300.00 = 6003.00).
• WIP swept — no 'V' rows remain (5 time / 3 expense all flipped to 'B'); the AR ledger carries 4 INVC postings, the trust ledger 2 new APP rows.

4. Run the monthly close: SBMJOB CMD(CALL PGM(LEXTIME/LXMONTH)). Confirm LTTRREC CLIENTS=2 BREAKS=0 NEG=0 and TOTAL TRUST LIABILITY=0.00, the aging buckets, and LTGLRPT TOTDIFF 0.00 / ARDIFF 0.00.
5. Review the balanced GL feed:

SELECT ACCT, DRCR, SUM(AMT) AS T FROM LEXTIME.LTGLFEED
  GROUP BY ACCT, DRCR ORDER BY ACCT;

Total debits must equal total credits. The BILLING leg debits 1200-AR for the invoice total and credits 4100-FEES (net billed fees) + 4200-EXP (expenses); the WRITEDWN memo pair (4900-WDWN / 4950-WDOF) self-balances; the TRUSTAPP leg moves 2300-TRLB to reduce 1200-AR by the trust applied.

E.3 Failure & re-run rules

Each program DSPLYs its result to the job log. Every cycle in LEXTIME/i is designed to be safely re-runnable through a stable-key idempotency guard — a re-run regenerates the same key and the duplicate write/insert is refused rather than double-posting.

F. Developer Reference ↑ top

The program surface, from src/sources.mjs. All objects are in library LEXTIME. The source is held as JS string constants (column-exact fixed-form RPG via the C()/D() helpers, plus free-form /free blocks) and loaded into library LEXTIME's source physical files by seedLextime() in src/seed.mjs — the same DEMOLIB convention as ibmi/samples.js.

F.1 Programs (13 RPG + 1 COBOL + 4 CL)

LTREFLD (RPG)

Seeds 4 clients (3 active + 1 closed), 4 timekeepers (3 active + 1 terminated) and 5 matters (4 active + 1 closed).

LTTRDEP (RPG)

Seeds initial trust deposits: C00001 1000.00, C00002 300.00; writes both the LTTRUST running-balance row and a DEP LTTRLDG row. Idempotent (CHAIN on the UNIQUE CLNO key).

LTTIMLD (RPG)

Loads 10 raw time cards + 5 raw expense cards (all 'E'), including the deliberate exception cards. Idempotent (sequential-counter key guard).

LTWIPED (RPG)

The daily edit. Walks each 'E' entry, applies E1–E5 checks, rates a clean time entry TFEE = THOURS × TRATE (half-adjusted) from the timekeeper's bill rate, flips to 'V' or 'R'. Re-CHAINs the entry after the master lookups moved the cursor. Idempotent.

LTWIPRP (RPG)

Reject exception report over the LTTIMLF/LTEXPLF status logicals (read-only), breaking rejects out by reason code.

LTBILL (RPG)

The billing engine. Per active matter: sum 'V' WIP, write-down on fees, expenses at cost, invoice total, MIN(total, balance) trust applied (never negative), AR remainder; writes header/detail, ledger rows, flips WIP to 'B'. Scans the base PFs for the sweep, deliberately not the status logicals — see F.4. Idempotent off the WIP gate.

LTBILPRT (RPG)

Prints the client invoice register to the LTBILP PRTF with page overflow (OFLIND(*IN90)): a matter block per invoice (header, itemised lines via a partial-key READE on BILNO, AR-posted net), then register totals.

LTARAGE (RPG)

Monthly AR aging. Buckets each open invoice's BARAMT − BPAIDAMT by age (30-day-month julian day-count) from BILDT to the fixed as-of date 20260913: CURRENT / B31 / B61 / B90.

LTTRREC (RPG)

Monthly trust reconciliation. Per client with a trust account, independently re-sums LTTRLDG (DEP adds, APP subtracts) over LTTRLLF and asserts it equals TRBAL to the cent; counts breaks and negatives; totals the trust liability.

LTGLDST (SQLRPGLE)

Monthly GL distribution. Sums the invoice headers and writes balanced DR/CR pairs into LTGLFEED with free-form exec sql insert. Idempotent (GLSEQ PK).

LTGLRPT (ILE COBOL)

GL trial balance over LTBILH: proves invoice total = billed fees + expenses (TOTDIFF) and AR posted = invoice total − trust applied (ARDIFF), both exactly zero.

LTMTRIQ / LTWIPIQ / LTMENU (RPG)

The three interactive programs (section B): plain matter inquiry, WIP subfile inquiry, and the menu that routes to them.

LTSETUP / LXDAILY / LXBILL / LXMONTH (CL)

The build/compile program and the three job cycles (section C).

F.2 The billing arithmetic (worked example)

Every figure below is hand-derivable and asserted to the cent by test/lt_cycles.mjs.

Note how the invariants show up in the totals: billed fees + expenses = total (6792.50 + 510.50 = 7303.00), total − trust = AR (7303.00 − 1300.00 = 6003.00), the write-down is per-matter (M00002/M00004 take none), and trust is capped at the balance (M00003 applies only 300.00 of a 1130.50 invoice), leaving both trust accounts at exactly 0.00.

F.3 The GL journal (double-entry)

LTGLDST posts three self-consistent legs, so the batch balances (DR = CR):

With the test's injected 500.00 orphan invoice included, the feed nets to: 1200-AR debit 7803.00 = 4100-FEES 7292.50 + 4200-EXP 510.50; the 4900/4950 memo pair 545.00; and 2300-TRLB debit = 1200-AR credit = 1300.00 (trust applied).

F.4 A platform finding — the cross-file-instance stale logical index

What LTBILL does and why. The billing engine deliberately opens only the base physical files (LTTIME/LTEXP) for its WIP sweep, never their status logicals (LTTIMLF/LTEXPLF), scanning SETLL *LOVAL / READ sequentially and filtering MTNO/TSTAT in RPG logic. This is a defensive redesign around a confirmed platform bug, logged as FINDING 1 in legal-app/FINDINGS.md.

The bug (confirmed). A logical file's keyed index does not observe an UPDATE posted through a separate, concurrently-open file instance over the same base PF / record format in the same job. The earlier version of LTBILL swept each matter's unbilled ('V') WIP via the status logicals, and for each row read through the logical it CHAIN-and-UPDATE-ed the same record through the base PF to flip it to 'B', then re-SETLLed the logical to reposition. The logical's index never saw the 'V'→'B' flip, so the next READE returned the same record (with its old key values) forever — an infinite READE loop looping on TENTNO 90000001 (matter M00001, timekeeper T00001). Left running, the 3-digit line-sequence counter WSEQ would eventually overflow past 999 and raise a second, misleading SNX0103 Receiver too small symptom that masked the true infinite loop.

Class & severity. This is the same class as the freight application's NA-02 finding (cross-file-instance index staleness). Severity High: it silently hangs the calling program with no error or escape message. On real IBM i, DB2/400 keeps a logical file's keyed index transactionally consistent with its base PF within a job across separate opens (single-job read-your-writes), so this specific shape either can't arise or the index would be maintained transactionally.

The fix (app-level, not a platform workaround). LTBILL was rewritten to scan the base PFs sequentially and filter in RPG — the same defensive shape staffing-app's SPCALC already uses (it opens only the base time PF, never its status logical, for exactly this reason). The status logicals remain in the app, used correctly (read-only, no same-run cross-instance UPDATE) by LTWIPRP, LTMTRIQ and LTWIPIQ, and the build battle still proves they are genuine, distinct keyed access paths. The platform gap itself remains present for any other program that would combine a keyed-LF sweep with a same-run UPDATE through a sibling file instance.

F.5 Reason-code & status table

Edit reason codes (TERRCD / XERRCD)

Status values

G. Glossary ↑ top

AR aging

Classifying each open invoice's outstanding balance by how long it has been unpaid (CURRENT / 31-60 / 61-90 / over 90 days). LTARAGE uses a 30-day-month julian approximation from BILDT to a fixed as-of date.

Billing run

The LXBILL cycle that sweeps validated WIP into invoices (write-down on fees, expenses at cost), applies trust funds and posts the remainder to AR.

Idempotent

Safe to run again with the same result. Every LEXTIME/i cycle is idempotent via a stable-key guard: the edit only touches 'E' rows, the card load's counter has advanced, billing's WIP gate is already 'B', the trust deposit's CLNO key exists, and the GL feed's GLSEQ PK collides.

IOLTA / trust account

Client funds a firm holds on the client's behalf (a liability, not the firm's revenue). Here one LTTRUST balance per client, drawn down by billing, and it may never go negative.

Matter

A legal engagement (case/file) for one client. Time and expenses are logged against a matter; a matter carries its own write-down percentage.

Realization / write-down

A discount applied to time fees before billing (the firm "realizes" less than its standard rates). WDPCT is the matter's write-down percentage; the amount is informational-memo'd, never a credit note against a receivable.

SBMJOB

Submit Job — the IBM i command that queues a program to run as a batch job (e.g. SBMJOB CMD(CALL PGM(LEXTIME/LXBILL))).

Stable business key

A key derived deterministically from the business data (here from client/matter digits + an offset) so a re-run regenerates the same key and the duplicate write is refused — the app's idempotency mechanism.

Subfile

A 5250 display construct listing many rows on one screen (DDS SFL/SFLCTL). LTWIPIQ's WIP list is a subfile.

Timekeeper

A person who logs billable time — partner, associate or paralegal — each with their own BILLRATE (charged to the client) and COSTRATE (internal cost).

Trial balance

The COBOL LTGLRPT report proving invoice total = billed fees + expenses (TOTDIFF 0.00) and AR posted = invoice total − trust applied (ARDIFF 0.00).

Trust reconciliation

The monthly LTTRREC check that independently re-derives each client's trust balance from the ledger and asserts it equals the running TRBAL to the cent, with no negatives.

WIP — Work in Progress

Validated but unbilled time and expense entries (status 'V'), waiting for the billing run to sweep them into an invoice.

Write-down line (W)

An informational invoice-detail line recording the write-down amount taken off gross time fees; it does not change what the client is billed (that is already net in BFEES).