LEDGER/i — General Ledger & Financial Close

LEDGER/i is a double-entry general-ledger and financial-close application: chart of accounts, journal-batch capture and validation, posting to the ledger and to account/period balances, a trial balance re-derived from the detail, recurring and accrual journals, period close, financial statement generation (P&L / balance sheet) and the year-end retained-earnings roll. The business logic is hand-written RPG (fixed-form C-specs plus /free) over keyed DDS physical and logical files, with one ILE COBOL statement generator and one SQLRPGLE summary-publish program. One accounting invariant is enforced everywhere: for every posted document SUM(DR) = SUM(CR), and because every ledger amount is stored debit-positive, SUM(GAMT) over the whole ledger is exactly zero. This manual is the reference for the operator who runs the four job cycles and the online screens, and for the developer maintaining the application. It is grounded entirely in the committed source (gl-app/src/sources.mjs, gl-app/src/seed.mjs, and the gl-app/test/gl_*.mjs drivers).

A. Overview & Architecture ↑ top

A.1 What it does

LEDGER/i runs the full life of a general ledger as four periodic job cycles:

• Capture & edit — an operator submits a batch of manual journal entries; the edit run re-adds each document's lines and validates debits=credits, account existence, account postability and that the target period is open, rejecting anything that fails (and rejecting the whole batch with it).
• Post — validated documents are written to the durable GL ledger (one signed, debit-positive row per line), the account life-to-date balance is moved, and the (year, period, account) balance row is accumulated.
• Recurring & accrual journals — the weekly cycle generates journals from templates: a recurring journal (a fixed entry repeated every period) and an accrual (posted at period end and auto-reversed the next period), then re-derives and prints the trial balance from the detail.
• Period close — the monthly cycle reverses the accruals into the following period, re-derives the balances, proves the period balanced, computes net income, publishes a summarised SQL extract for downstream consumers, and locks the period.
• Year-end roll — the annual cycle closes every revenue and expense account to zero into retained earnings, opens the new fiscal year's period calendar, and carries the balance-sheet accounts forward as opening balances.

A.2 Sign convention & the balance invariant

Two storage decisions carry the whole design and are worth stating up front:

• Unsigned magnitude + a side, in the detail. A journal line (GLJDTL) stores the amount LAMT as an always-positive magnitude and the side DRCR as 'D' or 'C'. Storing an unsigned amount plus a side is exactly what lets the edit run add debits and credits independently and compare them — the real double-entry check.
• Debit-positive signed, in the balances and ledger. The posted ledger amount GAMT, the account balance ACBAL and the period net PNET are all held debit-positive: a credit is stored negative. Under this one convention the whole ledger sums to zero when it balances, which is the cheapest possible integrity check — and it is the check GLBALCK (daily) and GLFINST (COBOL) assert directly. A credit-normal account therefore carries a negative life-to-date balance in storage; the online inquiry and the trial balance flip it back into normal-side presentation for the reader.

Everything runs in library LEDGER. The tested jobs run with LIBL = QSYS QGPL LEDGER QTEMP and CURLIB = LEDGER.

A.3 Component & flow

  DAILY  GLDAILY          WEEKLY GLWEEK           MONTHLY GLMONTH        ANNUAL GLYEAR
  --------------          --------------          ---------------        --------------
  GLJEGEN  (capture)      GLRECUR (gen R+A)       GLREVACC (reverse A)   GLYRCLS (close P&L->RE)
  GLEDIT   (validate)     GLPOST  (post)          GLTRIAL  (re-derive)   GLNEWYR (open new FY)
  GLPOST   (post)         GLTRIAL (re-derive)     GLCLOSE  (lock period) GLBALCK (prove)
  GLBALCK  (prove)        GLTBPR  (print TB)      GLSUMPB  (SQL extract) GLFINST (statements)
                                                  GLFINST  (statements)

     ONLINE (5250)                 files touched by the batch chain
     -------------                 --------------------------------
     GLMENU                        GLBAT  batch header (control totals)
       1 -> GLACCTIQ (GLACCTD)     GLJHDR journal header   GLJDTL journal lines
       2 -> GLJRNIQ  (GLJRND SFL)  GLLEDG posted ledger    GLBAL  period balances
                                   GLACCT chart (ACBAL)    GLPERD period calendar
                                   GLRECR templates        GLFSLN statement layout
                                   GLCLOG close log        GLSUMM SQL summary extract

A single daily event flows: GLJEGEN writes journal headers/lines at JSTAT='E' and recomputes the batch control totals → GLEDIT validates each document to 'V' or 'X' and rejects any batch carrying a failure → GLPOST turns each 'V' document's lines into GLLEDG rows, moves ACBAL and accumulates GLBAL, then flips the document to 'P' → GLBALCK re-derives SUM(DR) vs SUM(CR) from the ledger and reports OK/BAD.

A.4 Object inventory

The catalogue is 10 PFs + 2 LFs + 3 DSPFs + 1 PRTF + 1 SQL table + 1 SQL index, driven by 16 RPG programs (15 RPGLE + 1 SQLRPGLE-flavoured GLSUMPB), 1 COBOL program and 5 CL programs. Sections D and F expand each.

B. Online Transactions & Screens ↑ top

B.1 The command/entry line

LEDGER/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". The job's library list must include LEDGER.

All batch programs take no CALL parameters. Notably the app carries no online control-date table: the seeded worked example is hard-wired to FY2026, period 1 (GLJEGEN, GLRECUR, GLTRIAL, GLCLOSE and GLSUMPB all set wfy=2026; wpn=1 in-line), and the annual programs target FY2026→FY2027. This is an honest limitation of the sample: the periodicity is real (four distinct cycles) but the processing period is coded, not operator-supplied. See section F.3.

B.2 The menu & inquiry screens

Three interactive programs exist. GLMENU (over GLMENUD) is the driver; option 1 program-CALLs GLACCTIQ, option 2 program-CALLs GLJRNIQ, any other non-blank option shows Invalid option. and stays on the menu. F3 (CA03) returns from an inquiry to the menu, and again from the menu ends the session.

GLACCTIQ — account inquiry (plain DSPF, GLACCTD)

A non-subfile screen. Key an account number into IACCT and Enter; the program CHAINs GLACCT and renders the master record plus two balances: the stored Ledger balance (DBAL, the raw debit-positive ACBAL) and the Normal-side bal (DNBAL, derived — a credit-normal account's ACBAL is negated so an accountant reads it in its own sense). A miss clears every output field and shows Account not found.

GLJRNIQ — journal inquiry with a line subfile (GLJRND)

The app's subfile screen. Key a document number into IDOCNO; the program CHAINs GLJHDR for the header (description and the recomputed control totals), then SETLL/READE-walks GLJDTL to load one subfile row (JSFL under control JCTL, SFLPAG(5)/SFLSIZ(20), ROLLUP(25)/ROLLDOWN(26)) per line. Each enquiry clears and reloads the subfile, so switching from a 3-line to a 2-line document leaves exactly 2 rows; an unknown document shows Journal document not found. with an empty subfile.

B.3 Controls & audit workflow (no maker–checker, no online posting)

Honest statement: LEDGER/i does not model a four-eyes maker–checker workflow, and the online screens are inquiry-only — GLACCTIQ and GLJRNIQ read and display; neither posts, edits or authorises anything. Journals are captured and posted by the batch chain, not from a screen. The control model the application does have is enforced in the edit/post data layer:

• Batch as a unit of work. GLJEGEN recomputes the batch control totals (BDRTOT/BCRTOT) from the detail it wrote; GLEDIT validates every document and, if any document in a batch failed, rejects the whole batch (BSTAT='R', BERRCD='DB') — which is what a real GL does.
• The four edit checks. Per document GLEDIT proves: debits=credits (else 'DB'), every account exists and is active (else 'AC'), every account is postable (else 'NP' — the seeded header account 999000 is deliberately non-postable to exercise this), and the target period is OPEN (else 'PC'). A failing document goes JSTAT='X'; a clean one goes 'V'.
• Closed periods refuse postings. A perfectly balanced journal aimed at a period whose PSTAT='C' is still rejected with 'PC' and never reaches the ledger.
• Post is guarded and gated by state. GLPOST only posts documents at JSTAT='V', then flips them to 'P'; the ledger write itself is idempotent (stable key + CHAIN(EN) guard), so a re-run posts nothing.
• The ledger is the durable audit trail. Every posted line, recurring/accrual generation, reversal and year-end entry is a GLLEDG row tagged by source (GSRC M/R/A/V/Y), keyed by a stable business-derived LEDSEQ, so the full history is reconstructable and every key is unique. The period close writes a GLCLOG row per close event so a close can prove it did not close the same period twice.

In sum, the control posture is batch-level validation + state gating + a durable, uniquely-keyed audit ledger, all enforced in the edit/post layer, rather than a segregation-of-duties approval workflow or an online-entry authorisation gate.

C. Batch Jobs & the Periodic Cycle ↑ top

LEDGER/i runs as four cycles rather than one monolithic job: a daily capture/edit/post/prove chain, a weekly recurring-and-trial-balance chain, a monthly reverse/close/publish/statement chain, and an annual retained-earnings roll. Each cycle is a CL program that ADDLIBLE LIB(LEDGER) and CALLs its steps in order; each takes no parameters. A scheduled run is a bare SBMJOB.

-- one-time build, then the daily cycle
CALL PGM(LEDGER/GLSETUP)
CALL PGM(LEDGER/GLREFLD)               seed chart / periods / templates / statement layout
SBMJOB CMD(CALL PGM(LEDGER/GLDAILY)) JOB(GLDAILY)

C.1 Full batch program set

C.2 Daily / weekly / monthly / annual detail

Daily — GLDAILY (GLJEGEN → GLEDIT → GLPOST → GLBALCK)

The seeded worked example is five documents into batch 100001: four balanced (JE000001..JE000004) and one deliberately out of balance (JE000005, DR 1200.00 vs CR 1000.00). The edit run validates the four and rejects the fifth; the post writes 9 ledger lines (2+2+2+3), moves the account and period balances, and the balance-check proves the books.

Expected banners:
  GLJEGEN DOCS= 5 SKIP= 0
  GLEDIT VALID= 4 REJECT= 1
  GLPOST DOCS= 4 LINES= 9 SKIP= 0
  GLBALCK ROWS= 9 DR= 38500.00 CR= 38500.00 NET= 0.00 OK

Weekly — GLWEEK (GLRECUR → GLPOST → GLTRIAL → GLTBPR)

GLRECUR generates two documents into period 1 from the seeded templates: recurring JR100101 (DR 610000 100.00 / CR 150000 100.00) and accrual JA200101 (DR 600000 750.00 / CR 210000 750.00, flagged for reversal). Both enter at JSTAT='V' because they were built from a controlled template, so GLPOST picks them up (+4 ledger rows → 13). GLTRIAL then re-derives GLBAL for the period straight from the detail ledger (zeroing the period's rows first so a stale account cannot survive), which is exactly what catches a balance file that has drifted from the detail. GLTBPR prints it with a DR-CR difference of zero.

Expected banners:
  GLRECUR GENERATED= 2 SKIP= 0
  GLTRIAL ROWS= 9 DR= 39350.00 CR= 39350.00       38500 + 100 + 750
  GLTBPR LINES= ... DR= 39350.00 CR= 39350.00 DIFF= 0.00

Monthly — GLMONTH (GLREVACC → GLTRIAL → GLCLOSE → GLSUMPB → GLFINST)

GLREVACC reverses each posted accrual document (JSRC='A') by writing opposite-sign ledger rows into the following period (+2 rows → 15) — the standard accrue-and-reverse mechanic so the real invoice, when it arrives, is not double-counted. GLCLOSE accumulates the period from GLBAL, proves SUM(PDR)=SUM(PCR), computes net income (revenue − expenses, both restated positive), writes a GLCLOG row, and locks the period to PSTAT='C' only if it balanced (CSTAT='C'). GLSUMPB restates the period into GLSUMM (DELETE-then-INSERT, continuing SUMSEQ past other periods). GLFINST (COBOL) emits the statements.

Expected banners (period 1 close):
  GLREVACC DOCS= 1 LINES= 2 SKIP= ...
  GLCLOSE PER= 1 DR= 39350.00 CR= 39350.00 NETINC= 3150.00 ST= C
  GLSUMPB ROWS= ... DR= 39350.00 CR= 39350.00
  GLFINST REVENUE   15500.00
  GLFINST EXPENSE   11600.00     life-to-date: 9000 COGS + 2500 rent + 100 insurance
  GLFINST NETINC    3900.00      life-to-date; period-1-only net income is 3150.00
  GLFINST BSCHECK   0.00         assets+liabs+equity+rev+exp = 0

Annual — GLYEAR (GLYRCLS → GLNEWYR → GLBALCK → GLFINST)

GLYRCLS writes, for each revenue/expense account, a closing ledger entry equal to the opposite of its life-to-date ACBAL (zeroing it), then posts the net of those entries (the year's net income) to retained earnings 310000 so the whole set balances. After the roll every P&L account is zero and equity carries the result. GLNEWYR builds the FY2027 calendar (12 periods, period 1 open, the rest future) and carries only the balance-sheet accounts (A/L/Q) forward as GLBAL.POPEN for FY2027 period 1. GLBALCK and GLFINST re-prove the books.

Expected banners:
  GLYRCLS CLOSED= 4 NETINC= 3900.00 SKIP= ...
  GLNEWYR YEAR= 2027 PERIODS= 12 CARRIED= 5
  GLFINST REVENUE   0.00
  GLFINST EXPENSE   0.00
  GLFINST EQUITY    3900.00       retained earnings now carries the year result
  GLFINST BSCHECK   0.00

C.3 Ordering & dependencies

• Within the daily chain the order is fixed: capture, then validate (nothing posts until it is 'V'), then post (only 'V' documents), then prove. GLPOST is also the weekly cycle's post step for the generated journals.
• DAILY before WEEKLY. The weekly recurring/accrual journals post on top of the day's manual journals; the trial balance is only meaningful over a posted book.
• WEEKLY (accrual generated + posted) before MONTHLY. GLREVACC reverses posted accrual documents; if the accrual was never generated and posted there is nothing to reverse.
• GLREVACC before GLCLOSE. Within the monthly chain the accrual must reverse and the balances re-derive before the period is proved and locked, so the close reflects the reversal.
• MONTHLY closes before ANNUAL. The year-end roll closes the P&L life-to-date balances that the monthly cycles built up; run the periods first, then the year.
• GLYRCLS before GLNEWYR. The new year carries forward balance-sheet balances only after the P&L accounts have been zeroed, or a P&L account would wrongly carry forward.

D. Data Files (data dictionary) ↑ top

All files are in library LEDGER, grounded in sources.mjs. Dates are stored as packed/zoned integers in YYYYMMDD form; money is 13P 2 (packed decimal, 2 dp); the ledger sequence LEDSEQ is 15S 0 (widened from 8S0, see F.1).

GLACCT — Chart of accounts (key ACCTNO, UNIQUE)

Seeded chart (13 accounts): 100000 CASH, 110000 A/R, 120000 INVENTORY, 150000 PREPAID INSURANCE (assets, D); 200000 A/P, 210000 ACCRUED EXPENSES (liabilities, C); 300000 COMMON STOCK, 310000 RETAINED EARNINGS, 999000 SUMMARY HEADER (equity, C; 999000 is non-postable); 400000 SALES REVENUE (revenue, C); 500000 COGS, 600000 RENT EXPENSE, 610000 INSURANCE EXPENSE (expenses, D).

GLPERD — Accounting-period calendar (key FYEAR, PERNO, UNIQUE)

Seeded: FY2026 periods 1–3 open, period 4 future.

GLBAT — Journal-batch header (key BATNO, UNIQUE)

GLJHDR — Journal entry header (key DOCNO, UNIQUE)

GLJDTL — Journal entry lines (key DOCNO, LSEQ, UNIQUE)

GLLEDG — Posted GL ledger (key LEDSEQ, UNIQUE)

GLBAL — Period balances by account (key BFYEAR, BPERNO, ACCTNO, UNIQUE)

GLRECR — Recurring/accrual templates (key TMPLID, TSEQ, UNIQUE)

Seeded: RC0001 (recurring, DR 610000 / CR 150000, 100.00, not reversed) and AC0001 (accrual, DR 600000 / CR 210000, 750.00, reversed).

GLFSLN — Financial-statement layout (key STMT, FSLINE, UNIQUE)

Seeded: 3 P&L lines (revenue, expenses, net income) + 4 BS lines (assets, liabilities, equity, total). This turns a chart of accounts into a formatted statement without hard-coding layout in the program.

GLCLOG — Period-close log (key CLSEQ, UNIQUE)

GLSUMM — SQL summary extract (PK SUMSEQ)

DB2 table published by the monthly close for downstream consolidation: SUMSEQ, SFYEAR, SPERNO, ACCTNO, ATYPE, SDR, SCR, SNET, with index GLSUMACC (SFYEAR, SPERNO, ACCTNO). GLSUMPB restates one (year, period) per run (DELETE-then-INSERT), continuing SUMSEQ past other periods, and only totals a row into its banner when the INSERT actually succeeded (SQLCOD = 0).

Relationships & access paths

• GLJHDR.DOCNO → GLJDTL.DOCNO (header to its lines); GLJDTL.ACCTNO → GLACCT.ACCTNO.
• GLLEDG.ACCTNO → GLACCT.ACCTNO and GLLEDG.DOCNO → GLJHDR.DOCNO (posted line back to source).
• GLBAL is keyed on (year, period, account); GLACCT carries the life-to-date roll-up in ACBAL.
• GLACCLF — the chart keyed on ATYPE (then ACCTNO) so the statement generator walks assets, then liabilities, then equity in statement order without sorting.
• GLJDLF — journal lines keyed on ACCTNO, so an account-activity enquiry is a keyed read rather than a full document scan.

E. Operations Runbook ↑ top

E.1 Day-in-the-life

1. First-time only: CALL LEDGER/GLSETUP then CALL LEDGER/GLREFLD to build the objects/programs and seed the chart, calendar, templates and statement layout.
2. Confirm the target period is OPEN (PSTAT='O' for FY2026 period 1 in the seeded sample).
3. Submit the daily cycle: SBMJOB CMD(CALL PGM(LEDGER/GLDAILY)).
4. Post-check the banners (below).
5. On the weekly day, submit GLWEEK; check GLRECUR GENERATED=, the trial balance and GLTBPR ... DIFF= 0.00.
6. Answer account/journal enquiries through CALL LEDGER/GLMENU (option 1 or 2).

Pre-checks: the job's library list includes LEDGER; the seeded example targets FY2026 period 1 and is open.

Post-checks after the daily cycle:

• GLEDIT VALID= 4 REJECT= 1 — the four balanced documents validated, the out-of-balance one rejected; the batch is BSTAT='R' with BERRCD='DB'.
• GLPOST DOCS= 4 LINES= 9 — only 'V' documents posted; the rejected document contributed nothing.
• GLBALCK ... DR= 38500.00 CR= 38500.00 NET= 0.00 OK — a trailing OK, DR=CR, net zero.
• Re-running the chain moves nothing (idempotent): cash 100000 stays 9500.00 and the ledger stays 9 rows.

E.2 Period-end & year-end close

1. Confirm the period's daily runs and the weekly recurring/accrual run have all posted (the accrual must be posted before it can be reversed).
2. Submit GLMONTH. Confirm GLREVACC DOCS= 1 LINES= 2, GLCLOSE PER= 1 ... NETINC= 3150.00 ST= C (a ST= E means the period did NOT balance and was not locked), and the SQL extract / COBOL statements below.
3. Verify the period is locked: GLPERD period 1 now PSTAT='C' with a PCLSDT. A later journal aimed at it will be edit-rejected with 'PC'.
4. At year-end submit GLYEAR. Confirm GLYRCLS CLOSED= 4 NETINC= 3900.00, GLNEWYR YEAR= 2027 PERIODS= 12 CARRIED= 5, and that every R/E account is now zero with retained earnings 310000 carrying -3900.00 (a credit, i.e. a profit).

Review the close log and the SQL extract:
SELECT CFYEAR, CPERNO, CDRTOT, CCRTOT, CNETINC, CSTAT FROM LEDGER.GLCLOG;
SELECT SUM(SDR), SUM(SCR), SUM(SNET) FROM LEDGER.GLSUMM;   39350.00 = 39350.00, 0
SELECT SUM(SCR) FROM LEDGER.GLSUMM WHERE ATYPE = 'R';      15500.00 revenue

E.3 Reconciling figures (balanced-GL checks)

These are the same figures the daily and cycle suites derive by hand from the five seeded documents and assert against an independent oracle — every one is checkable in production the same way. The single master check is the signed ledger sums to zero.

• Posted debits = posted credits. 15000 + 9000 + 2500 + 12000 = 38500.00 DR; 15000 + 9000 + 2500 + 11500 + 500 = 38500.00 CR (9 lines). GLBALCK re-derives this from GLLEDG and must print OK.
• Account life-to-date balances (debit-positive), after the daily post. 100000 cash +9500.00; 110000 A/R +3500.00; 120000 inventory −9000.00; 400000 revenue −15500.00; 500000 COGS +9000.00; 600000 rent +2500.00; 150000 & 200000 stay 0.00 (their only journal, JE000005, was rejected). Signed sum = 0.00.
• Period balances tie to the posted totals. SUM(PDR) and SUM(PCR) over the period each equal 38500.00 (daily) / 39350.00 (after weekly), and SUM(PNET)=0. A cash period row keeps turnover separately: PDR 12000.00, PCR 2500.00, PNET 9500.00.
• Trial balance re-derived from the detail. GLTRIAL rebuilds GLBAL straight from GLLEDG and GLTBPR must print DIFF= 0.00. A non-zero DIFF means the incremental balance file has drifted from the ledger — investigate before closing.
• Period net income. Period 1: revenue 15500.00 − expenses 12350.00 = 3150.00 (GLCLOSE CNETINC). Life-to-date after the reversal: 15500.00 − 11600.00 = 3900.00 (GLFINST NETINC).
• The accounting identity. Assets 3900.00 = Liabilities 0.00 + Equity 3900.00 after the roll; GLFINST BSCHECK (assets+liabs+equity+rev+exp, debit-positive) must be 0.00.
• Carry-forward balances self-check. The FY2027 opening balances sum to zero (9500 + 3500 − 9000 − 100 − 3900 = 0); 5 balance-sheet accounts carry forward, no P&L account does.

E.4 Failure & re-run rules

Every program DSPLYs a one-line banner; a healthy daily run ends in GLBALCK ... OK. All four cycles are safely re-runnable because every write is keyed off a stable business key and guarded.

F. Developer Reference ↑ top

Fixed-form RPG (C-specs) plus /free over keyed DDS, one ILE COBOL program and one embedded-SQL RPG program. All objects are in library LEDGER, held as source-physical-file members (loaded by seed.mjs' seedLedger()).

F.1 The ledger key (LEDSEQ)

Every posting program contributes to one accumulating GLLEDG history keyed UNIQUE on LEDSEQ, derived entirely from a stable business key so a re-run regenerates the same key and the CHAIN(EN) guard refuses it rather than double-posting. Ranges are disjoint per program so keys never collide across cycles:

• GLPOST (journal post): 10000000000000 + prefixcode×10^9 + docbody6×1000 + line.
• GLREVACC (accrual reversal): 30000000000000 + ... (same fold).
• GLYRCLS (year-end close): 50000000 + account digits.

The 2-character document prefix is folded in via a character-set scan (%scan(ch:WCSET)) so JE000001 and SM000001 can't collide, and the full 6-digit document body is folded in losslessly. LEDSEQ was widened from 8S0 to 15S0 precisely to hold this: an 8-digit field could only keep a lossy 3-digit slice of the 6-digit body, so JE000123 and JE100123 (same prefix, same last 3 digits) collided — the second validated cleanly but its lines were silently swallowed by the idempotency guard, stuck at JSTAT='V' with no diagnostic. The widened, full-body fold makes distinct documents impossible to collide while a genuine re-post still regenerates the identical key.

F.2 Programs

GLREFLD — reference-data loader (RPGLE)

Writes the 13 accounts, 4 periods, 4 template lines and 7 statement lines. Idempotency is by the caller not re-seeding; the members are fixed.

GLJEGEN — journal capture (RPGLE)

Builds the five seeded documents under fixed DOCNOs, recomputes each document's DR/CR and the batch control totals from the detail. CHAIN(EN) guards on (DOCNO,LSEQ) for lines and DOCNO for headers make it idempotent (SKIP= counts skips).

GLEDIT — edit/validate (RPGLE)

Per 'E' document: checks period open (else 'PC'), walks the lines summing DR/CR and checking account exists+active ('AC') and postable ('NP'), then DR=CR ('DB'). Sets JSTAT V/X and recomputes JDRTOT/JCRTOT. A separate pass rejects any batch that carried a failing document.

GLPOST — post (RPGLE)

Per 'V' document: for each line writes a debit-positive GLLEDG row under the stable key (F.1), moves ACBAL, and accumulates the (year,period,account) GLBAL row (gross PDR/PCR + signed PNET); then flips the header to 'P'.

GLBALCK — balance proof (RPGLE)

Reads GLLEDG, sums positive amounts as DR and negatives as CR and totals the signed net; prints OK when DR=CR.

GLRECUR — recurring/accrual generation (RPGLE)

Control-breaks on TMPLID; each template becomes one document numbered stably from the template id + period (JR100101, JA200101), source R/A, entering at 'V'. Copies ACCTNO out to a work field before the write because GLRECR and GLJDTL share the field name (see F.3).

GLTRIAL — trial-balance re-derivation (RPGLE)

Two passes: zero the period's existing GLBAL rows, then re-accumulate straight from GLLEDG — catching any drift between the incremental balances and the detail.

GLTBPR — trial-balance print (RPGLE/PRTF)

One line per non-zero period balance in normal-side presentation (positive net → debit column, negative → credit), then totals and the DR-CR difference (must be zero). Page overflow via OFLIND(*IN90).

GLREVACC — accrual reversal (RPGLE)

Per posted JSRC='A' document: writes opposite-sign GLLEDG rows (source 'V') into jperno+1 and moves ACBAL back.

GLCLOSE — period close (RPGLE)

Accumulates the period from GLBAL, computes net income from R/E accounts, writes a GLCLOG row (CSTAT C if DR=CR else E) and locks the period (PSTAT='C') only when it balanced. Guarded by the GLCLOG key.

GLSUMPB — SQL summary publish (SQLRPGLE)

Embedded-SQL DELETE of the period then INSERT per non-zero balance, continuing SUMSEQ past other periods. Only totals a row into the banner when SQLCOD = 0 — a refused insert is not reported as published.

GLYRCLS — year-end roll (RPGLE)

Pass 1 closes each R/E account with an opposite-of-balance GLLEDG row and zeroes it; pass 2 posts the net (year income) to retained earnings 310000 so the set balances. Keyed 50000000 + account.

GLNEWYR — open new fiscal year (RPGLE)

Builds the FY2027 12-period calendar (period 1 open, rest future) and carries each non-zero balance-sheet account (A/L/Q) forward as GLBAL.POPEN for FY2027 period 1.

GLACCTIQ / GLJRNIQ / GLMENU — online (RPGLE)

Account inquiry, journal-line subfile inquiry, and the menu driver (see B.2).

GLFINST — financial statements (ILE COBOL)

Reads GLLEDG and randomly reads GLACCT by account, accumulates assets / liabilities / equity / revenue / expense (debit-positive), computes net income (0 − revenue) − expense, and the balance-sheet check assets+liabs+equity+rev+exp which must be zero.

F.3 Engine-compatibility accommodations (documented in source)

• DDS conditioning-indicator columns (GLJRND). This emulator's DDS parser reads a bare two-digit indicator from columns 9–10 and a negated one from columns 11–13, one column off the real IBM i spec. The subfile keywords are therefore written shifted so SFLCLR is conditioned on indicator 31 (not 3) and actually clears, SFLDSP/SFLDSPCTL on N31, and SFLEND on 90 (not 9). The build suite asserts the parsed conditions, not just keyword presence.
• Shared record field name (GLRECUR). GLRECR and GLJDTL both carry a field called ACCTNO, sharing one storage location; the template account is copied to WACC before the GLJDTL write, or the write would clobber the value it needs.
• Edit-code K presentation. The 5250 balances render via %editc(...:'K'): thousands separators and a trailing minus, so a stored −15500.00 shows as 15,500.00- and its flipped normal-side balance as a clean 15,500.00. This is real AS/400 edit-code behaviour, not a defect.
• Hard-wired processing period. The worked example is coded to FY2026 period 1 (and FY2026→FY2027 for the roll); there is no operator control-date table. The periodicity is real, the period value is not operator-supplied.

F.4 Error codes & banners

G. Glossary ↑ top

Accrual (accrue-and-reverse)

An expense recognised at period end (DR expense / CR accrued liability) and auto-reversed the following period so the real invoice, when it arrives, is not double-counted. Here template AC0001, reversed by GLREVACC into jperno+1.

Batch (journal batch)

The unit of work an operator submits — a set of documents with control totals (GLBAT). One failing document rejects the whole batch.

Chart of accounts

The account master (GLACCT), keyed by ACCTNO, typed A/L/Q/R/E with a normal side D/C.

Control totals

The batch DR/CR totals (BDRTOT/BCRTOT) recomputed from the detail and compared — the classic batch-integrity check.

Debit-positive

The sign convention for stored balances and the ledger: debits positive, credits negative, so the whole ledger sums to zero when it balances.

Double entry

Every document has SUM(DR) = SUM(CR); over the whole ledger SUM(GAMT) = 0. The app's master invariant.

Idempotent

Safe to run again with the same result. Every posting program derives a stable ledger/log key and guards it with CHAIN(EN), so a re-run posts nothing.

Net income

Revenue − expenses, both restated positive from debit-positive storage. Period net income (GLCLOSE) and life-to-date net income (GLFINST) can differ — know which you're reading.

Normal side

The side an account normally carries (NORMDC). Debit-normal for assets/expenses, credit-normal for liabilities/equity/revenue. The online inquiry flips stored debit-positive balances into normal-side presentation.

Period close

Proving a period balances, recording net income, and locking it (PSTAT='C') so no further journal can post into it. GLCLOSE; logged in GLCLOG.

Posting

Turning validated journal lines into durable GLLEDG rows and moving the account/period balances. GLPOST.

Recurring journal

A fixed journal repeated every period (e.g. straight-line prepaid amortisation), template RC0001, generated by GLRECUR.

Retained-earnings roll (year-end close)

Closing every revenue/expense account to zero into retained earnings, then opening the new fiscal year with carried-forward balance-sheet balances. GLYRCLS + GLNEWYR.

SBMJOB

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

Subfile

A 5250 display construct listing many rows on one screen (DDS SFL/SFLCTL). GLJRNIQ's line list is a subfile, cleared and reloaded per enquiry.

Trial balance

Every account's period turnover/net, re-derived from the detail ledger (GLTRIAL) and printed (GLTBPR) with a DR-CR difference that must be zero.