Close Items in Depth

This page documents the major close items Kraal automates as part of the month-end close workflow. Each item is template-driven (see Client Setup & Close Workflow) and runs when its predecessors finish; this guide focuses on the substance of each item — what gets computed, what gets posted, and what to look for in review.

TIP

All automatically generated close-item journal entries appear in the client's audit trail. See Audit Trail & Activity Log for how to review history.

For the period-by-period math behind Debt, Leases, Prepaid & Deferred, and Fixed Assets, download a Formula-Driven Register Workbook. It is a traceable Excel working paper with live formulas and a Kraal tie-out; the existing CSV and Excel register exports remain static snapshots.

Tax Provision

Computes the period's income tax provision using a CPA-grade ASC 740 reconciliation rather than a flat book × rate multiplication.

What it computes:

• Taxable income = pre-tax book income + permanent differences + temporary differences
• Current tax = taxable income × combined rate (the cash payable)
• Deferred tax = -temporary differences × combined rate (the timing shift)
• Total book tax expense = current + deferred = (book + permanent) × rate

Configuration:

• Effective rate (or) Federal rate + State rate — when both federal and state are configured, the proposal can split current tax into two journal entries with separate accounts
• Expense + payable accounts for each rate channel
• Deferred tax accounts (optional) — when configured, deferred tax produces a separate journal entry against the deferred asset / liability
• Book-to-tax adjustments — list of permanent and temporary differences with label, amount, and direction (add / subtract)
• YTD true-up (on by default) — Kraal subtracts what's already been booked in the current fiscal year so monthly re-runs only post the delta, not the full YTD amount

What you see in metadata:

• A reconciliation block tracing pre-tax → adjustments → taxable income → federal/state current → deferred → total → YTD already booked → period delta
• A separate proposal per channel (federal, state, deferred) when accounts are configured

Review checklist:

• Confirm the period's pre-tax income source matches what you'd accrue
• Sanity-check the effective tax rate against the company's recent ETR
• For deferred, confirm the temporary differences haven't reversed since the last period

Bad Debt Allowance

Computes the required allowance for doubtful accounts using an aging-bucket percentage model, and posts the delta against the existing allowance — never the full amount.

What it computes:

• Aging buckets per outstanding receivable: current / 30 / 60 / 90 / 120+ days
• Required allowance per bucket × the configured rate, summed across buckets
• Existing allowance balance (from trial balance or GL)
• Period adjustment = required − existing

Customer-level visibility:

The result includes a per-customer aging breakdown — top 25 customers by exposure with their total outstanding, oldest age, and per-bucket detail. Use this during review to see who is driving the allowance rather than just the aggregate.

Specific write-offs:

If you configure a write-off age threshold, Kraal flags invoices aged beyond it as write-off candidates with their customer, age, and outstanding amount. Write-off proposals are always review-only — they need explicit sign-off and proper invoice linkage when posted.

Configuration — all of these live in the client's close configuration, editable from the close settings UI:

• Aging percentages per bucket (defaults are conservative)
• Expense account (P&L) — typically Bad Debt Expense
• Allowance account (BS contra-asset)
• Recovery account (optional) — for when the required allowance drops below existing and you're releasing reserve
• Write-off age days (optional) — enable specific write-off proposals

Review checklist:

• Look at the top-customer view: are the aging totals reasonable?
• Confirm the existing allowance balance source — Kraal will note whether it pulled from trial balance closing or GL net activity
• For write-off candidates, verify each invoice is genuinely uncollectible before posting

Prepaid Amortization & Deferred Revenue

Both items follow the same pattern: the client provides recurring amortization schedules; Kraal computes the period's straight-line recognition amount and posts it.

Schedule fields:

• Total amount
• Number of periods (e.g., 12 for monthly over a year)
• Current period index (which period are we in?)
• Debit and credit accounts

What Kraal does correctly:

• Cent-residual — the final period absorbs any rounding remainder so the schedule totals exactly back to the original amount
• Past-the-end — schedules whose period_index has exceeded periods are recognized as completed and skipped. Re-running a closed schedule will not over-recognize
• Missing index — when no period-index field is present, Kraal still recognizes the base amount but flags the schedule so you know the residual cent won't post automatically

Changing a schedule's terms — correct a prepaid or deferred-revenue schedule's total, number of periods, or accounts after it has begun recognizing, and Kraal records the change; the next close then proposes a one-time catch-up (a "true-up") that reconciles what already posted to the corrected schedule, as a review proposal you accept or reject. See Corrections & Adjustments.

Review checklist:

• Spot-check that the per-period amount matches your schedule
• Confirm completed schedules are showing as such (you may want to retire them)
• For schedules flagged as "not tracked," add a current-period field so the final-period catch-up will fire next year

Revenue Recognition (ASC 606)

For clients that recognize revenue under contracts with distinct deliverables, Close Prep gains a revenue contract register. Each contract carries a name, customer, total transaction price, start and end dates, a status (active, completed, or cancelled), a running billed-to-date figure, and notes. Within a contract you add one or more performance obligations, each with an allocated amount and one of four recognition methods.

For the readiness panel and the Dashboard, Contracts, Customers, and Transactions review workflow, see Revenue Contracts & Recognition.

The four recognition methods:

• Straight-line — the allocated amount spread evenly over a number of periods from a start date, with the final period absorbing any rounding remainder (the same cent-exact convention as prepaid schedules).
• Milestone — each milestone's amount is recognized in the month it's marked completed. The milestone amounts must sum to the obligation's allocation.
• Usage — you report a figure for each month and Kraal recognizes it exactly as reported. Usage can run past the allocation when actual usage is high.
• Point-in-time — the full allocation in the delivery month. Until a delivery date is set nothing recognizes, and the obligation shows as pending delivery.

Each close, Kraal proposes the period's recognition per obligation — debiting the configured deferral account and crediting revenue.

Review policy: straight-line and usage entries can auto-post under the client's automation policy, like other schedule items. Milestone and point-in-time proposals always wait for a person's review — they assert that a real-world event (a completed milestone, a delivery) happened, which is a human call. Missing accounts or broken terms block auto-posting for the whole item — never a partial batch — and surface as configuration gaps to fix in Close Prep.

Contract position workpaper — every close also produces a per-contract workpaper showing the total transaction price, billed to date, revenue recognized through the period, this period's recognition, percent complete, and the resulting balance-sheet position: a contract liability when billing has run ahead of recognition, or a contract asset when recognition has run ahead of billing. Billed-to-date is a cumulative figure you (or your ERP) maintain; Kraal reads it to derive the position.

One surface per revenue stream — clients already using the simpler deferred-revenue schedules keep working unchanged. Use either contracts or simple schedules for a given revenue stream — never both for the same revenue, or it recognizes twice. An empty contract register is perfectly healthy when deferred-revenue schedules already cover the domain. Kraal watches for the overlap: when active contracts and deferred-revenue schedules are both configured, the item and its workpaper carry a dual-surface warning, and if the contract item also proposed recognition that month, the item is held for review so a person confirms the two surfaces cover different streams before relying on the period's revenue. If Kraal can't verify the schedule side at run time, proposals likewise wait for review instead of auto-posting.

Changing a started contract — correct an obligation's method, allocation, dates, or number of periods after it has begun recognizing, and Kraal records the change; the next close proposes a one-time catch-up (a "true-up") as a review proposal. Backdated events — a milestone completed in an already-closed month, usage added to a past month — work the same way. An obligation or contract with recognized history can't be deleted; cancel the contract instead. See Corrections & Adjustments for the full flow.

Review checklist:

• Confirm each obligation's allocation ties back to the contract's transaction price, and that milestone amounts sum to their allocation.
• For usage obligations, sanity-check the month's reported figure before it posts.
• Read the workpaper's contract liability / asset: a growing liability means billing is running ahead of delivery, which is usually expected for advance-billed work.
• Clear any configuration gaps (a missing deferral or revenue account) before closing — they hold the entire item, not just one contract.

Payroll Accruals

Computes the period-end payroll accrual based on:

• Gross per pay period
• Pay frequency (biweekly, semimonthly, monthly)
• Date of last completed payroll
• Optional payroll tax rate

Kraal accrues gross × (accrued_days / period_days) plus the tax portion, producing two journal entries (wages accrual and payroll-tax accrual) with auto-reversal flagged — these will reverse on the first day of the next period.

Review checklist:

• Verify the last payroll date is current
• For first-time payroll periods, confirm gross per period
• After posting, confirm the auto-reversal lands in the next open period

Depreciation

Kraal prefers the connected ERP's native depreciation tool, which knows about each asset's useful life, salvage value, and schedule. The native path posts depreciation entries automatically; Kraal reports the count of entries created.

When the native tool is unavailable, Kraal falls back to the fixed-asset register you maintain in Close Prep. Register assets carry cost, salvage value, in-service date, useful life, and method (straight-line or double declining; intangibles are always straight-line), and Kraal computes real per-asset depreciation proposals from them — with a full-month in-service convention, no depreciation in the disposal month, and the final period absorbing rounding so each asset fully depreciates to salvage exactly.

If your assets already live in the ERP, use Import from ERPNext on the Fixed Assets panel to pull them into the register instead of re-keying them; already-imported assets are skipped automatically.

Every close also produces a fixed-asset rollforward (beginning cost, additions, disposals, depreciation, ending balances, by asset class) as a reviewable workpaper.

When you correct a register asset's terms — its useful life, salvage value, or method — after depreciation has already posted, Kraal records the change and the next close proposes a one-time catch-up (a "true-up") that reconciles the amounts posted under the old terms to the corrected schedule. It arrives as a review proposal like any other: accept to post it, reject to dismiss. See Corrections & Adjustments for the full flow.

Inventory & COGS

Your ERP owns stock. Every receipt, issue, transfer, and physical-count adjustment is recorded there, and its stock valuation is the authority on what inventory is worth. Kraal's inventory close item does not recompute stock — it ties the general ledger out to that valuation, maintains the obsolescence reserve around it, and reports margin. Think reconciliation and reserve, not a second stock system.

The item runs in three parts, all driven by close configuration:

• Inventory rollforward & tie-out — for each configured inventory account, Kraal builds the beginning GL balance, the period's movements in and out, and the ending GL balance. When the ERP's stock valuation is readable, it compares that ending balance to the ERP's stock value at period end; a difference beyond the configured variance threshold flags the item for review with the details attached. The usual causes are a manual journal entry booked straight to an inventory account, or a cost that posted outside the stock system.
• Obsolescence / shrink reserve — the required reserve is computed either from aging buckets (a percentage against each band of the ERP's stock aging) or, when aging isn't available, a flat percentage of ending inventory. Kraal posts only the delta against the reserve already on the books — never the full amount: an increase debits obsolescence expense and credits the reserve, and a release flows to the recovery account when one is configured. Like the bad-debt allowance, the delta can auto-post under the client's automation policy.
• COGS & margin diagnostics — when COGS accounts are configured, Kraal reports the period's cost of goods sold, the gross margin, and a flag when margin swings more than the configured threshold against the prior month. These are diagnostics for the reviewer: they never post an entry and never block the close.

Configuration:

• Inventory accounts — the GL accounts Kraal rolls forward and ties out
• COGS accounts (optional) — turn on the cost-of-goods and margin diagnostics
• Reserve, expense, and recovery accounts — the reserve (a balance-sheet contra-asset), the obsolescence expense (P&L), and the recovery account a release credits
• Reserve percentages — either a rate per aging band or a single flat rate; percentages use the same convention as the bad-debt aging model
• Variance threshold — how far GL and stock may diverge before the item flags for review
• Margin-swing threshold — how large a month-over-month margin move must be before it's flagged

What you see:

• An inventory rollforward workpaper per account — beginning balance, movements in and out, ending balance, and (when available) the ERP's stock value beside it with the variance
• A variance flag when GL and stock diverge beyond the threshold, carrying the difference and the accounts involved so you can trace it
• The reserve delta for the period — required reserve versus the existing balance, and the entry that squares them
• The margin diagnostic — period COGS, gross margin, and any month-over-month swing that broke the threshold

When the ERP's stock figures aren't available:

If Kraal can't read the ERP's stock valuation or aging for the period, the close still completes. The rollforward runs GL-only and says so plainly on the workpaper, the reserve falls back to the flat percentage of ending inventory, and nothing is fabricated — a missing stock figure is reported as missing, not filled in. You get an honest GL-based close with a note about what couldn't be tied out.

Review checklist:

• On a variance flag, chase the cause at the source: look for manual journal entries posted directly to inventory accounts, or costs booked outside the stock system. The close item is the detector; the correction belongs in the ERP (see Corrections & Adjustments).
• Sanity-check the reserve against the aging — does the proposed obsolescence reserve look reasonable for how old the stock actually is?
• Follow up on a flagged margin swing before you lean on the number; a large move often points to a cost or cutoff issue worth understanding, even though the diagnostic itself posts nothing.

Debt Interest Accrual

For clients with loans, add a debt schedule (principal, term, start date, annual rate as a percent — 6.5 means 6.5%/yr, and an optional payment override). Kraal computes the effective-interest amortization table and accrues the period's interest expense each close. The final period retires the balance exactly, and the full payment/interest/ principal/balance schedule is available as a workpaper.

Correcting a loan's rate, term, or principal after interest has posted records the change, and the next close proposes a one-time catch-up (a "true-up") for the cumulative interest difference — a review proposal like its prepaid and fixed-asset siblings. See Corrections & Adjustments.

Lease Accruals (ASC 842)

For leased assets, add a lease schedule per lease: classification (operating or finance), initial lease liability, term, commencement date, discount rate, and the liability / right-of-use accounts. Each close, Kraal accrues:

• Liability interest accretion — effective interest on the lease liability
• Right-of-use amortization — straight-line for finance leases; for operating leases the single lease cost is recognized straight-line and the ROU amortization is the difference between that cost and interest

Both balances run off to exactly zero by end of term, and the combined liability + ROU schedule ships as a workpaper. Lease payments themselves are assumed to arrive through your normal AP/bank flows and are not re-posted by the close.

Modifications — when a started lease is renegotiated, change it with the Remeasure action rather than editing the schedule in place. You provide a modification date (in the current month or a past one) and either an explicit new liability or the revised payment, term, and/or rate. Months already recognized stay as posted; Kraal re-derives the remaining schedule from the modification date and surfaces the right-of-use / liability adjustment at the next close as a review proposal. Leases that haven't commenced can still be re-keyed directly. See Corrections & Adjustments for the step-by-step.

Cutoff Analysis

Looks at GL activity across a window around the period boundary (period-end ± 5 days) and surfaces entries that may have been misposted to the wrong period:

• Creation-vs-posting gap > 7 days — an entry posted on the 30th but created on the 10th of the next month suggests a back-date that may warrant explanation
• Posting-date / creation-date period mismatch — an entry posted in one period but actually created during another

These are surfaced as review items, not corrections. The reviewer decides which (if any) need adjustment.

Accrual Identification

Kraal looks for accruals the period appears to be missing — a recurring vendor with no bill this period, an accrual booked last period with no twin this period, or a schedule that produced no entry — and proposes each one with the reason why and the records behind it. Nothing posts without a person's approval, accepted accruals can carry an automatic reversal, and a genuinely recurring one can be promoted into a standing schedule.

See the dedicated page: Accrual Identification.

Errors & Risk Review

Kraal checks the period for duplicates, posting errors, and risk signals — duplicate entries and vendor payments, round-figure manual entries, weekend or backdated postings, uncleared suspense activity, and statistically unusual amounts. Each finding carries a severity, the reason it was flagged, and the underlying records, and is resolved, dismissed with a reason, or escalated. The item posts nothing.

See the dedicated page: Errors & Risk Review.

Period Closing Voucher (PCV)

The final close step submits the period closing voucher in your ERP, which locks the period and zeroes income/expense to retained earnings.

Kraal will not run the PCV until all prerequisite items are complete (trial balance, reconciliations, accrual entries, depreciation, deferred revenue, prepaid amortization, revenue recognition, inventory reserve, debt interest accrual, lease accruals, cutoff analysis). It also won't run if the ERP's fiscal year configuration is missing or the retained earnings account is not set.

By default, PCV auto-submits when the client's automation policy allows it. Clients that prefer manual submit can disable auto-submit per template; the policy still drafts the voucher but leaves the submit step to a human.

Intercompany Reconciliation

See the dedicated page: Multi-Entity & Intercompany Reconciliation.

FX Revaluation

See the dedicated page: FX Revaluation.

What if a close item fails?

• Configuration errors — Kraal returns a clear missing_*_config error naming the field. Fix in close configuration and re-run.
• Transport errors — temporary ERP-side failures are flagged as retryable; running the item again often succeeds.
• Imbalances or thresholds breached — Kraal returns the item as needing review, with the imbalance details in metadata. Fix the underlying data before re-running.

Each close item has a stable identifier (tax_provision, bad_debt_allowance, revenue_recognition, inventory_reserve, etc.) used in the audit trail, so the full history of each run — what was configured, what posted, what was skipped — is reviewable in the Audit Center.