Step-by-step user guide

From first launch to signed audit pack. Use the sidebar (or the bar above on mobile) to jump to any section — every section ends with “what you should see”. Sample figures are the bundled JUL-26 data. The short Quick Guide stays the two-page desk reference; this page is the full manual.

01Getting started — open the app and load the sample

Goal: the app is running in your browser with a finished reconciliation on screen. About five minutes the first time.

1. Unzip the LedgerMatch folder anywhere on your PC.
   • Use the versioned folder as-is (e.g. LedgerMatch-0.1.3). Never merge it into an old install — each release carries its version in the folder name so extractions can never mix builds.
2. Open the folder and double-click Launch LedgerMatch.bat.
   • If Windows SmartScreen warns “Windows protected your PC”, click More info → Run anyway. The launcher is an unsigned local script that only serves files to your own machine — there is nothing to install and nothing is uploaded.
   • A black PowerShell window appears and stays open. Leave it open while you work — closing it stops the app. Minimising it is fine.
3. Wait for the browser. A tab should open by itself at http://127.0.0.1:8477.
   • If no tab opens, open your browser yourself and type that address. Bookmark it — it is the same every launch.
   • If the page refuses to load, the launcher window probably shows an error, or another copy is already running (see Section 14).
4. Look at the Upload & pre-flight view. You should see, top to bottom:
   • an insight strip naming the active template (oracle-ar-gl) with a Pre-flight badge,
   • a callout: “First look? Run a full reconciliation on the bundled sample export (264 AR lines, 35,401 GL lines).” with a Load sample data button,
   • two drop cards: AR Transactions (receivables side) and GL Journal Lines (ledger side).
5. Click Load sample data.
   • The button briefly reads Loading… and is disabled while the 35,401 GL lines parse — this takes a few seconds, entirely inside your browser.
   • When both files land, the reconciliation runs automatically. A green Reconciliation Ready callout appears: “Both AR and GL datasets are loaded and reconciled.”
6. Click Open Recon Cockpit →. The left rail unlocks every view and the cockpit dashboard loads with the figures in Section 03.

02Loading your files & reading pre-flight

Goal: both report exports loaded, pre-flight badge reading READY, and you know what every check line means.

1. Export the two reports from your ERP or accounting system for the period you are closing (CSV or XLSX; XLSM/XLS also open):
   • your AR Transactions export — line-level receivables with transaction number, receivables account, GL date and line amount;
   • your GL Journal Lines export — journal lines with account code, entered debit/credit and period name.
   • Any period works. Keep the originals untouched — the app only reads them.
2. Put the AR file on the AR card. Three equivalent ways:
   • drag the file from Explorer and drop it anywhere on the AR Transactions card (it highlights while you hover);
   • click the card to open the file picker;
   • keyboard: Tab to the card, press Enter or Space to browse.
   Either card accepts either file — the active template decides which columns matter, so there is no “wrong card”.
3. Put the GL file on the GL card the same way. Parsing starts immediately; only mapped columns are read, so a very large GL file is normal.
4. Read the counters under each card. A loaded card shows N data rows · M columns in file. If required columns are missing you will see red missing: … text naming them — that must be fixed (step 7) before the run can pass.
5. Read the Pre-flight badge (top insight strip): READY in green means zero errors and the run is unblocked; N ERRORS in red means the reconciliation is blocked until you fix them. The warning count beside it is advisory only.
6. Open the Data-quality pre-flight panel (it appears once both files are loaded). Its chip reads Passed (green), Blocked (red), or Reconciling… while a run is in flight. Every row shows an icon — ✕ error, ! warning, · info — plus the title, a count where relevant, and a detail line with examples.
7. Work the rows top-down: all errors first.
   • Missing required columns → your headers are renamed (or it is the wrong export). Either re-export with standard headers or map the real names once in Templates (Section 10) — no code change needed.
   • No data rows → the file has headers but zero rows; re-export the period.
   • AR and GL share no common period → wrong file pair, or a non-English Excel month locale. Confirm the AR months overlap the GL periods; otherwise check the template period setting with whoever set it up.
8. Then note the warnings (they inform the run, they never block it):
   • Duplicate column names → two headers differ only by case/spacing; the first is used. Rename at source if it bothers you.
   • Duplicate AR match keys → two AR lines share account + transaction + period. Both are kept; GL matches the first. Worth a glance — clients sometimes double-export.
   • Unbalanced journals / trial balance out of balance → journal nets exceed 0.005. Genuine journals net to zero, so chase these in the source system.
9. Read the info rows as confirmation: AR lines with an amount but no transaction number (can never match — the exact-key match skips them), GL lines on AR accounts without a transaction number (your expected exception population), currency mix (lists the codes seen), debits-credits balance, and the perfect-month notice.

03Running the reconciliation & reading the control total

Goal: a finished run you trust, starting from the one number that matters — the control tie-out.

1. Let the automatic run finish. Loading the second file (or the sample) triggers the recon by itself. The pre-flight chip reads Reconciling… while it works; the top-bar button reads Working…. On the sample data this takes seconds.
2. Re-run deliberately after any change. Use the top-bar ↻ Re-run whenever you reload a file, switch template, change materiality, or accept a smart match. With no result yet the same button reads Run reconciliation.
3. Read the control tie-out FIRST, before any other figure. Control = variance + GL exceptions.
   • Tied — variance is 0.00 and there are no exceptions. Perfect month: sign it off (Section 11).
   • Explained — variance is non-zero but the control is 0.00. Every ringgit of the gap sits on an identified exception line. The sample data lives here.
   • Review — the control is non-zero. Something is genuinely unexplained: work Section 05, then Section 06, and document the remainder in sign-off.
4. Understand what matched and what did not. Matching is exact-key on account | transaction number | MMM-YY — the AR period comes from the GL date, the GL period from the Period Name — with a 0.005 tolerance. Smart matching (Section 06) only ever proposes; the recon itself never fuzzy-matches.
5. Check the six control figures against the table below (sample data, JUL-26). If yours differ on your own files, that is expected — these numbers are the sample-data fingerprint that proves the engine reproduces the macro exactly.

04Reading the cockpit, block by block

Goal: a repeatable top-to-bottom reading order. Start here every close — it takes five minutes once you know the path.

1. Open Recon cockpit (rail group Reconciliation, or the top-bar switcher, or the ☰ drawer on mobile).
2. Read the control banner. Status word (Tied / Explained / Review) plus the control figure. Say it out loud: “Explained, control zero — the gap is fully itemised.” If it says Review, skip to Section 05 now and come back.
3. Scan the six KPIs underneath: AR total, GL net, variance, AR exception count, GL exception count, control. They are the same six figures as Section 03 — the cockpit just puts them where the drill-through starts.
4. Follow the variance bridge, left to right. Three bars chain the story: AR subledger total → GL opening balances, no trx # → GL net on AR accounts. The middle bar is the bridge: it shows how much of the walk from AR to GL is explained by unkeyed opening balances. On sample data it carries the full (929,247.88).
5. Glance at the GL composition donut to feel the mix (matched vs exception populations), then go to the main event:
6. Work the account reconciliation table.
   • Each row is one account: AR Line Amount, GL Net Entered, Variance, AR/GL exception amounts, Status. Click any column header to sort — start with the largest absolute variance.
   • Click a row to drill through. A drawer opens with the exact AR and GL source lines behind that account. This is the evidence the macro could never give you: every figure, one click from its proof.
   • Close the drawer (✕ or Escape) and pick the next account. Work the top three variances first; the tail rarely matters.
7. Check GL exception groups — click a group card to open every journal line inside it (rows sort, Escape closes). Then the two summary tables:
8. Largest unmatched GL journals — click a row for its full exception detail; opening-balance conversions carrying no transaction number, biggest first. These names should match what finance told you was migrated; anything unfamiliar goes on the query list.
9. Read aging by value across the seven buckets — click a bucket to open every line due in it (trx, customer, due date, days, amount — collections ready), then oldest open items and population composition.
   • Buckets: Not yet due · Current · 31-60 · 61-90 · 91-180 · 181-365 · Over 1 year;
   • Sample fingerprint: 1,123,183.07 not yet due · 48,829.80 current · 13,526.93 over one year.

The AR / GL summary indexes (Reports group)

The two pivot views — receivables accounts × month, every GL segment × period — are the searchable index over the same numbers. Type into Search accounts to shrink the list; flip Exceptions only to keep just segments sitting in the exception registers (on sample data the 532 GL rows collapse to the handful that matter); Hide zeros drops flat rows. The totals row always covers all rows, and the counter reads “Showing N of M”. Click any row to drill through to its source lines, exactly like the cockpit table.

05Working the exception lists

Goal: every exception row triaged to a status, with the source evidence checked — this list is the close.

1. Open AR exceptions first (rail group Exceptions). AR-side rows have exactly one reason: No matching GL transaction — “we billed it, GL never saw it”. Treat every one as high priority: unposted revenue is the worst kind of surprise.
   • On sample data this list shows the “all matched” clean state — zero rows. That is the correct answer for this dataset, not an empty bug.
2. Open GL exceptions. GL-side rows carry one of two reasons:
   • Missing GL Transaction Number — typical for converted opening balances legitimately outside the subledger;
   • No matching AR transaction — a keyed journal the subledger never saw; chase these.
   Sample data: 71 rows, all the first kind.
3. Read a row across its columns — source row number, account, amount, period, journal/batch/source details. The table opens sorted by amount, biggest first — the material items lead without you touching Excel. Click any column header to re-sort.
4. Trace a row to its source. Note the source row number, open the uploaded file, and go to that row. What you see there is what the engine saw — amounts, transaction numbers, dates. If the file and the row disagree, suspect a re-export or a re-sorted file, then re-run.
5. Click the row for the full detail drawer when the flat columns are not enough. Escape or ✕ closes it; focus returns to the row you opened (rows are keyboard-focusable — Tab to one, Enter to open).
6. Triage at keyboard speed (optional but fast). click anywhere on the page first; then j / k (or ↓ / ↑) walk the shown rows with a highlight band, Enter opens the cursor row’s drawer, x ticks or unticks it for the bulk bar. j/k ignore the search box and never fire while you are typing.
7. Clear a row with one click. Each row carries a single action under Write-off:
   • Write off on Open / Investigating rows;
   • Reopen on written-off rows — Reopen puts the row back the way it was (an Investigating row returns to Investigating, not Open);
   • Resolved rows show an em dash — nothing left to do;
   • Every click confirms in the bar beside the table with Undo.
   • New rows arrive as Open. The status tabs under the search box (All · Open · Investigating · Resolved · Written-off, each with a live count) filter the table: click a status to see only that status, click All to see everything — one click answers the stand-up question “what is still Open?”.
   • Resolved means evidenced and tied; Written-off means formally accepted as a permanent difference (e.g. historical conversion balances). Both keep the row visible — statuses never delete evidence, and statuses never move the numbers: they are reviewer memo, and only open items print onto the follow-up register (Section 11).
8. Work the 71 identical rows as one. On GL exceptions, flip Group identical to collapse journals sharing account + period + source + reason into single lines with counts (the 71 conversion rows become a handful). Statuses live on detail rows — switch it off to work them.
9. Take what you need out of the app, and let the app keep the state.
   • Copy shown ↓ puts the currently visible rows on the clipboard as tab-separated text — paste into Excel and the columns land correctly, each row with its Status, Owner and Note;
   • A thin N of M worked meter in the action bar fills as rows leave Open — progress Excel never shows you;
   • Take the extract out, then come back: the app keeps the tie-out, statuses and drill-through.
10. Work many rows at once: select, then Apply.
    • Select the checkboxes (or Select all shown (N) — it selects the rows currently visible);
    • Read the selected count and sum in the bar — Excel's status-bar sum, built in;
    • Set status to, type an owner, then Apply once for all selected rows — converting 71 opening balances to Written-off is one apply;
    • The selection clears after applying, and Undo restores the previous statuses;
    • The same checkboxes feed Journal ↓ — next point.
11. Prove persistence to yourself once: change two statuses, refresh the browser, re-run the reconciliation — both statuses survive. They live in this browser (IndexedDB ledgermatch → workflow, keyed by side + source row). Clearing site data wipes them; they do not sync between machines (Section 12).
12. Name an owner and leave a note. Click any row to open its drawer.
    • Below the facts sit Owner (e.g. Aina) and Reviewer note ("queried AP 12 Aug, chasing invoice") — both save as you type and travel with the status;
    • Spot annotated rows in the list: a small dot in the Note column (hover it for the text), and the With memo N chip shows only annotated rows — the note trail is filterable, not invisible;
    • At export the memo rides along to the Follow-up sheet of the audit workbook and the open items onto the follow-up register (Section 11);
    • Older installs that stored bare statuses keep working: they load as ownerless, noteless rows.
13. Turn rows into a correction (adjusting journal). Select the checkbox on each row the journal should fix, then click Journal ↓ above the table.
    • In the drawer: name the journal (ADJ-JUL-26), set the accounting period, enter the offset account (the balancing side — e.g. a suspense account), write the narration, and set the currency;
    • Pick the upload format: Generic CSV, SAP CSV or Oracle FBDI .xlsx;
    • Auto-reverse next period for timing items — it appends mirror lines into the reversal period;
    • Preview: line count with Dr = Cr. Positive amounts debit the exception account and credit the offset; negatives flip;
    • Export journal ↓ downloads the file — nothing posts automatically; upload it in Oracle/SAP yourself.
    • FBDI/SAP files carry the documented column shape — fill ledger, source and company against your upload spec before importing.

06Smart matching — clearing unkeyed journals properly

Goal: decide, for each GL journal missing a transaction number, whether a genuine AR twin exists — and book that decision as a re-run, not a fudge.

1. Open Smart matching (rail group Exceptions) whenever the GL list shows Missing GL Transaction Number rows. The head of the view counts unkeyed journals against unmatched AR rows so you know the size of the puzzle.
2. Read each proposal across its columns — GL side, then AR twin, then confidence:
   • GL side: GL row, account, period, journal, GL amount;
   • Proposed AR twin: AR trx number, AR row, AR amount;
   • Confidence band (100% = exact amount match ± 0.005).
   Pairs are built on account + period + amount (signed, greedy 1:1) and drawn only from unmatched AR rows, so accepting one can never break the control identity.
3. Accept a pair you have evidenced with Accept:
   • It fills the missing GL transaction number with the AR transaction's number and re-runs the reconciliation — the same remedy as correcting the source file;
   • The pair moves to the Accepted matches panel (with an Accepted N chip) as your audit trail;
   • Volume made easy: the search box narrows candidates, Accept all shown (N) accepts a whole filtered set with one-click Undo, and Copy shown ↓ pastes the proposals into Excel for whoever needs them.
4. Reject what you cannot evidence with Reject. Rejections are remembered for the session so the same pair stops being offered.
5. Undo freely. Every accepted match carries Undo, which returns the journal to exceptions — “Undo returns the journal to exceptions.” There is no way to paint yourself into a corner here.
6. Leave true orphans alone. Unkeyed conversion or opening-balance journals with no AR twin stay in exceptions — they are part of the variance, not matchable noise.

07Timing differences — catching month-end cutoffs

Goal: separate “wrong month” from “wrong forever”. Most real-world variances are cutoffs — invoiced 31 Jul in AR, posted 2 Aug in GL — and they clear themselves next period once you have named them.

1. Open Timing differences (rail group Exceptions, right after Smart matching) whenever exceptions survive Section 05 with no matching proposal in Section 06. The head chips count AR exceptions, keyed GL exceptions (only journals carrying an invoice number can prove a cutoff — unkeyed conversion balances never propose here), Proposals and Confirmed.
2. Read the three KPIs: Proposals waiting, Confirmed timing value (AR-side memo — the amount to collect or watch next period), and Engine variance (remains exactly as reconciled — confirmations never move it).
3. Read each proposal across its columns — GL side, AR side, cutoff direction, confidence:
   • GL side: GL row, account, period, journal, amount;
   • AR side: AR row, account, invoice/trx number, amount;
   • Cutoff direction: AR JUL-26 → GL AUG-26 means billed a month before posting; the reverse means GL posted first;
   • Confidence band (100% = exact amount match ± 0.005).
   Pairs require the same account, invoice and amount with periods exactly one month apart — including across December→January — assigned greedily 1:1 so no ringgit is explained twice.
4. Confirm what you have evidenced with Confirm:
   • The pair joins the Timing Differences (Cutoff) panel as a reviewer tag — not a rebooking: engine, control total and exports stay exactly as reconciled;
   • Confirmations persist in this browser (IndexedDB ledgermatch → timing) and are content-keyed, so they survive re-runs and re-sorted exports;
   • For volume: search to narrow, Confirm all shown (N) with one-click Undo, and Copy shown ↓ for the spreadsheet hand-off.
5. Dismiss what you cannot evidence with Dismiss. Dismissals last for this session; the pair proposes again next run.
6. Undo freely with Undo — in the confirmed panel or in Confirmed earlier — not in this run, where pairs confirmed on previous files that no longer propose are kept for follow-up. They should clear when the next period posts; if they linger, chase them as permanent exceptions.
7. Close the loop next month: when the GL side posts into the new period, the AR line matches normally and the confirmed pair goes stale — that staleness is the proof the cutoff resolved. Report confirmed-then-cleared pairs as the timing story of the close.

07aCredit netting — the memo that was applied on both sides

Goal: when a credit note is applied against an open invoice, the subledger legitimately shows two lines while GL often posts one net journal — the macro calls that two permanent exceptions. Netting turns them into one evidenced pair.

1. Open Credit netting (rail group Exceptions, right after Timing differences). The head chips count AR exceptions, unkeyed GL journals, Proposals and Netted.
2. Read each proposal across its columns — the pair, then the GL net vehicle:
   • Customer + currency group the legs belong to;
   • Invoice exception (row + amount);
   • Credit memo beside it (negative);
   • Net = invoice + memo — the unkeyed GL journal carries exactly this on the same account and period (± 0.005, either Dr or Cr direction);
   • Greedy pairing: the biggest invoice covers the biggest fully-coverable memo first; a memo that would over-cover waits for a bigger invoice.
3. Nothing is double-explained: a memo whose own GL journal already keys on its transaction number is never proposed — netting is only for memos GL has not seen separately.
4. Evidence the pair, then Confirm — a reviewer tag printed as Netted Credit Application. Like timing, it changes no figure; Confirm all shown (N), Dismiss all shown and Undo work the volume; Copy shown ↓ takes the table to Excel; confirmations persist in IndexedDB ledgermatch → netting.
5. Settle-the-loop evidence next close: when GL keys both legs normally and the memo is applied, the proposal disappears — the pair is proven resolved.

07bBalance-sheet split — MFRS 15 presentation, proven per line

Goal: the financial statement's receivables note expects gross trade debtors (MFRS 9) separated from unapplied cash and customer deposits/advances (MFRS 15 contract liabilities). This view does the split from your own subledger labels — no assumed figures.

1. Open Balance-sheet split (rail group Analysis). Four KPIs: Gross trade receivables (MFRS 9), Unapplied cash, Customer deposits & advances (contract liability) and the Net carrying amount that ties to the recon's AR total.
2. Read the classification audit trail: every bucket is a rule hit on Class/Type labels — unapplied-cash and deposit/advance keywords by default, or your template's own rules (Section 10 Step 5). Lines that match no rule default to Trade — defaulting is shown as its own row, never hidden.
3. Act on the indicative reclassification card when a liability balance exists — Dr Trade receivables / Cr Contract liabilities — amount. It is an analysis to inform management's statement preparation, not a posting: sign-off remains with management and appointed auditors.
4. Sample-data expectation: clean, fully-billed AR → everything is Trade, unapplied and deposits are zero, and the view says exactly that. If your subledger labels deposits differently, add a rule on your template and they appear here.

08Segments & aging — who owes what, where

Goal: the same recon, pivoted by responsibility — so each owner sees only their slice, and the slices provably add up.

1. Open Segments & aging (rail group Analysis). The panel sub says it plainly: “Balances, variance and exception value pivoted by segment dimension. Totals must tie to the recon summary.”
2. Pick a dimension and read it fully before switching: Company, Division, Cost center, Account, or Intercompany. Each row shows balance, variance and exception value for one segment value; columns sort.
3. Check the tie chip on every dimension. Green Ties to recon totals means the pivot adds back to the recon summary exactly — proceed. Red Does not tie means stop and report it, because a pivot that does not tie is worse than no pivot.
4. Read AR aging per segment value (built from due dates) to aim collection effort: which company, division or cost center holds the overdue value, and how old it is.
5. Turn the pivot into actions: screenshot or export the slice for each owner meeting (full register export is Section 11), assign the segment’s exceptions in Section 05, and re-check the chip next run.

09Period compare — proving the close is converging

Goal: month-on-month proof: what cleared, what appeared, and a control trend heading to zero.

1. Save the current run first. In Period compare (rail group Analysis), type a period name into Save current run as… (it defaults to the detected period — e.g. JUL-26 close is a good name) and click Save current run. The run joins the saved list with its variance and exception counts. Saving is local to the browser.
2. Build the habit monthly: save every close. One saved run is a snapshot; three are a trend.
3. Pick a baseline. In the saved-runs list click Set baseline on the older run — it flips to Baseline ✓. Click again to unpick. Delete dead runs with Delete (this only removes the snapshot, never source data).
4. Read the diff panel titled Exceptions: {baseline} → current run. Three buckets with amounts:
   • raised — in the current run but not the baseline (new problems, or new business);
   • cleared — in the baseline but gone now (the team’s wins — report these);
   • recurring — in both (the hard core to attack next month).
   Identities are content-based (account + reference + period + amount), so re-sorted exports still compare correctly.
5. Read the control-total trend across every saved run. A healthy close shows the control walking toward zero; a flat line at a big number is the conversation to have with finance.
6. Sanity-check the machinery once: save a run, refresh, reload the same files, save again, baseline the first — identical runs show everything recurring and 0 raised / 0 cleared.

10Templates — mapping your own report pair

Goal: a renamed-header (non-Oracle) pair reconciling identically with zero code changes. Follow the clicks exactly the first time; it takes ten minutes.

1. Load the file pair FIRST (or the bundled sample). Open Templates (rail group Governance) without loaded files and the Template builder panel shows the guided empty state instead of the mapper: “A template maps your report’s real column names — so those columns need to be loaded first.”
   • Click Load sample data right there, or Go to Upload & pre-flight to load your own pair. Then come back — the file’s columns appear on the left.
   • The bundled sample uses the standard sample layout, so a template built on it works for any pair with the same layout.
2. Name the template in Template name * — e.g. Client X AR/GL July. The name is required; saving stays disabled without it.
3. Pick the AR side tab (AR side / GL side segmented switch) and map every required field (marked *). AR required: trxNumber · account · glDate · lineAmount.
   • The panel instruction is literal: “Pick a file column on the left, then click a field to map it.” Click a column (it highlights as picked), then click the recon field card. Mapped columns tint; the picked one goes solid.
   • Clicking an already-mapped field selects its column for a swap — assigning a held column auto-swaps, so duplicates cannot be created from the UI.
   • Map the optionals you have too: accountDesc, distGlDate, distAccount, dueDate, overdueDays, currency, customer, trxClass, trxType, invoiceNumber, batchName. Unmapped optionals are tolerated — that is by design, not sloppiness.
4. Switch to the GL side tab and map its required fields: periodName · account · enteredDr · enteredCr · trxNumber, plus optionals (sourceName, categoryName, batchName, journalName, documentNumber, lineDescription, accountType, currency). Watch the required-progress counter under the field list per side.
5. (Optional) Define your own segment dimensions. Under the mapping sits the Segment definition (optional) table:
   • Each row = label + AR column + GL column, picked from this pair's own headers;
   • A non-Oracle chart can define Company / Division / Region however it exports them — Segments & aging picks the new dimensions up the moment the template activates (tie chip included);
   • A row with any text must be complete on both sides — incomplete rows stop the save with a clear message;
   • Imported templates carry their segment rows through.
6. Click Save & activate template. The button enables only once the name and every required column are mapped (hover it — the tooltip tells you what is missing). Saving stores the mapping locally and makes it the active template for the next reconciliation; the Active: … chip at the top of the Templates view confirms the switch.
7. If saving is refused, read the red box. “This mapping cannot be saved — N problems found:” lists each problem, and field problems add “→ fix the AR/GL field (marked red)” — the offending field card is marked red and scrolled into view. Fix and re-save. The common messages:

7. Share templates as JSON. Each saved template row has Export JSON (and Delete). On this or any other machine, click Import JSON, pick the file — it is validated, stored locally and activated immediately. A failed import shows Import failed: … with the reason. Templates are stored in the browser (ledgermatch → templates).
8. Re-run after activating (top-bar ↻ Re-run) and confirm the control figure matches the default-template run on the same files. A renamed-header pair reconciling identically is the proof the mapping is right — and it is covered by test, so it stays right.

10bGR/IR accrual reconciliation & close pack

Goal: reconcile SAP Ariba purchase-order receipts against Oracle Fusion General Ledger goods-receipt accruals, classify timing vs price/quantity variance with 9 deterministic root causes, bucket aging, and export an ink-ready 4-sheet Close Pack.

1. Activate the GR/IR Accruals model. Open Templates (rail group Governance) and select the built-in SAP Ariba PO Receipts ↔ Oracle Fusion GL template (oracle-grir).
   • The model adjusts the ingest and reconciliation engine: the primary match key transitions to Receipt ID ↔ GL Ariba Reference.
   • GL accrual lines are aggregated across line entries while excluding designated clearing accounts (default 2190000), evaluating net variances against a configurable monetary tolerance (default ±50 USD).
2. Ingest procurement receipts and accrual journals. On Upload & pre-flight, load your goods-receipt extract on the left card and GL accrual journals on the right card (or test instantly with the GR/IR sample payload).
3. Inspect the 9-Category Root-Cause Classifier. Every unmatched line or variance is deterministically evaluated into one of 9 audit-grade categories:
   • Timing difference: Receipt recorded near cutoff; invoice or accrual journal posted in subsequent cycle.
   • Price or quantity variance: Unit rate or quantity discrepancy between PO receipt and GL voucher.
   • Partial posting: Partial goods receipt or staged accrual recognized against multi-line PO.
   • Missing GL entry: Physical receipt confirmed in Ariba but no offsetting accrual journal in GL.
   • GL entry with no receipt: Manual journal entry posted to clearing account lacking a valid Receipt ID.
   • Duplicate GL posting: Multiple accrual lines posted against the identical receipt voucher.
   • Account coding error: Journal booked to incorrect natural account or invalid cost center.
   • FX rate difference: Discrepancy arising from transaction-to-functional currency conversion.
   • Journal not posted: Unposted draft or batch holding up ledger balance reconciliation.
4. Analyze Aging Buckets. Accrual variances are automatically grouped by elapsed days from receipt date to period close:
   • 0–30 days: Current-period activity (normal operating window);
   • 31–60 days: Follow-up candidates requiring vendor invoice verification;
   • 60+ days: Stale accruals requiring write-back or formal audit exception review.
5. Export the 4-Sheet Close Pack. In GR/IR mode, the top bar button dynamically renders as Export close pack ↓ (matching the dedicated button on the Recon Summary view). Generating the pack delivers a styled, macro-free Excel workbook (.xlsx) containing:
   • GRIR Summary: Executive control dashboard, total receipt value vs GL accrual net, tie-out variance, and root-cause breakdown;
   • Recon Statement: Formal reconciliation schedule detailing matched pairs, classified variances, and aging distribution;
   • Exception Log: Line-item register of unmatched receipts and orphaned journals with transaction metadata;
   • Accrual Certification: Audit sign-off sheet with ISA 230 / MFRS compliance statements and preparer/reviewer signature blocks.

11Export & audit pack — the evidence out the door

Goal: a styled 6-sheet workbook on file plus a named, dated sign-off page ready for the audit file.

1. Export the workbook. Click Export workbook ↓ in the top bar (or the Export workbook buttons in Recon summary / Audit pack). A single .xlsx downloads — generated in your browser, macro-styled in navy.
   • Walk the six sheets in order:
     • Recon Summary — workpaper banner, the six control figures with tick-marks, per-account AR vs GL vs variance with status, grouped GL-exceptions summary, control identity stated in words, tick legend + disclaimer;
     • AR Summary — receivables accounts × AR GL-date month;
     • GL Summary — every GL segment × period;
     • AR Exceptions — the full AR exception register;
     • GL Exceptions — the full GL exception register;
     • Follow-up — every exception from both sides with its Status, Owner, Reviewer Note and Age Days (the reviewer memo recorded in the app, open items first — the register CSV below is the open-items working extract).
   • Every sheet carries the row-4 workpaper banner (WP Ref · Entity · Reg No · Period · Prepared by · Reviewed by · Date) and closes with the tick legend and disclaimer.
   • Formatting is audit-file glass: title bands, header fills, totals rows, frozen panes, accounting money formats, and text-format account columns (leading zeroes like 00112000 preserved — accounts are never parsed as numbers).
2. Open Audit pack (rail group Governance) — the recon’s formal sign-off page.
   • Workpaper identity: WP Ref (default AR-REC-01), plus entity + registration number once filled;
   • Control block: AR total [SL], GL net [TB], variance [∑], AR/GL exception amounts, Control [∑];
   • Evidence sentence naming the exception count and amounts;
   • Tick-marks state each figure's provenance: [SL] vouched to the subledger listing, [TB] agreed to the GL trial balance, [∑] cast and verified (ε ≤ 0.005). The legend is printed on the page and in the workbook.
3. Fill the sign-off slots — six fields, each with a full-width underline:
   • Entity legal name (e.g. Contoh Sdn Bhd);
   • Registration No. (SSM/UEN);
   • WP Ref — edit per engagement;
   • Prepared by and Reviewed by (full names);
   • Date (defaults to today).
   Exporting from this page stamps all six onto the workbook banner; exporting from the top bar uses the WP Ref default with the rest blank. Then write the Variance explanation / notes:
   • Tied run? Record what substantiates the zero — e.g. “Opening balances migrated from legacy system on conversion journals; substantiated to migration certificate ref …”
   • Open difference? “Explain the unresolved difference and the action planned…” — name the owner and the date, not just the amount.
4. Click Print / PDF. The printed page drops the app chrome (rail, topbar, buttons) — what remains is the sign-off document, suitable for the audit file. File it with the workbook; the footer line “Sources — AR: {file} · GL: {file} · Reconciled with LedgerMatch.” ties the two together.
5. Download the follow-up action register. Beside Export workbook sits Follow-up register ↓:
   • Open exceptions only — Open + Investigating; Resolved and Written-off rows are done and stay out;
   • Both sides (AR + GL) in one CSV, with status, owner, reviewer note and age in days counted from each row's period-end;
   • Sort by Age Days descending and the meeting agenda writes itself — oldest unactioned items first.
   File it with the pack and work it down next close.

12Managing your data — what lives where

Goal: no surprises about what survives a refresh, a clear-out, or a new laptop.

1. Back up what matters before clearing anything: Export JSON every custom template (Section 10 step 7) into the period’s audit folder. Statuses and projects cannot be exported yet — plan the close around one machine per period.
2. Clearing browser data for the app origin wipes statuses, projects, and custom templates. If the team must clear cache, do step 1 first, then re-import the JSONs after.
3. Moving machines, step by step: copy the two report files + template JSONs across → launch the app on the new machine → load the pair → Import JSON each template → re-run → re-apply statuses. Expect a bare workflow board: statuses stay on the old machine.
4. Private / incognito windows fall back to memory: everything works, nothing persists past the session. The app shows a dismissible notice instead of failing silently — if you see it, switch to a normal window for real work.

13Upgrading to a newer version

Goal: new build running, all local data intact, old folder deletable.

1. Close the running app properly: close the browser tab, then close the black PowerShell launcher window. This frees port 8477 for the new copy.
2. Unzip the new release BESIDE the old one — never merge. The folder inside carries the version in its name (e.g. LedgerMatch-0.1.3), so it can never mix with the old install.
3. Open the new folder and double-click Launch LedgerMatch.bat (same http://127.0.0.1:8477 address).
4. Confirm your data carried over: statuses, saved projects and custom templates live in the browser against that address, not in the folder — so with host and port unchanged, everything is still there. Check the cockpit figures, one workflow chip, and the Templates list.
5. Finish up: if anything looks stale after the upgrade, press Ctrl+F5 once (the launcher serves pages no-store, so this is rarely needed). The app version sits at the bottom-right of the status bar — confirm it reads the new number. Then delete the old folder.

14Troubleshooting & FAQ — find your symptom

Goal: every common failure recognised in one table, fixed in one action. Work top-down from your symptom.

15Glossary