Corrections & Adjustments Playbook

Real months don't follow the happy path. This page covers the common "something needs to change" scenarios: what kind of change each one is, where you make it, and what Kraal does afterward.

A useful distinction throughout:

• One-time fixes correct a specific month (a wrong posted entry).
• Systemic fixes change the configuration so every future month is right (a schedule's terms, an asset's life, a policy).
• Many situations need one of each — fix the data going forward and correct what already posted.

A schedule or asset was set up wrong

Example: a van was entered with a 60-month life that should be 36, or a prepaid was keyed at the wrong total.

Edit the asset in Close Prep → Fixed Assets or the schedule in its Schedules tab. Validation guards you (salvage can't exceed cost, rates are percentages, lease and debt terms must be complete). Because recognition is computed from dates and terms — not running counters — the very next close uses the corrected math automatically.

You no longer book the catch-up by hand. When you change the terms of a fixed asset, prepaid, or deferred-revenue schedule, Kraal records the change, and the next close proposes the cumulative catch-up — a one-time "true-up" that reconciles what already posted under the old terms with what the corrected terms say should have posted through today. Accept it to post the adjustment; reject it to dismiss it and leave the prior postings untouched. If you make several edits before the next close, the catch-up is computed from the final terms, so stacked changes still resolve to the right number.

The catch-up belongs to the period where the change was recorded. Rerunning an earlier period computes with the terms that were in effect during that period, so a historical rerun neither pulls the change backward nor double-counts what the true-up already covers.

This applies to fixed assets, prepaid and deferred-revenue schedules, and debt schedules alike — a changed loan rate or term proposes a catch-up for the cumulative interest difference the same way. One exception:

• Started leases don't take direct term edits — change them with the Remeasure action instead (see A lease's terms changed below).

A lease's terms changed

Example: a started lease is renegotiated to a lower monthly payment, or its term is extended.

How you change a lease depends on whether it has commenced.

• Before commencement — nothing has been recognized yet, so edit the lease's terms freely in the Schedules tab. The first close simply uses the new terms.
• After commencement — a started lease won't accept direct term edits; use its Remeasure action instead. Give it a modification date (in the current month or a past one) and either an explicit new liability or a revised payment, term, and/or rate. Months already recognized stay exactly as posted — Kraal re-derives only the remaining schedule from the modification date forward, and the resulting right-of-use / liability adjustment appears at the next close as a review proposal (accept to post, reject to dismiss).

A revenue contract's terms changed

Example: a milestone was actually completed last month, not this one, or a started obligation's allocation was keyed too high.

Revenue contracts follow the same change-in-estimate rhythm as schedules. What matters is whether the change concerns the current month or a past one.

• Current-month events are just close input. Entering this month's usage figure, or marking a milestone completed this month, isn't a correction at all — the close simply proposes that period's recognition.
• Backdated changes propose a catch-up. Marking a milestone completed in an already-closed month, adding usage to a past month, or changing a started obligation's structure (method, allocation, dates, or number of periods) records the change, and the next close proposes a one-time catch-up — a "true-up" reconciling what already posted with the corrected terms. It arrives as a review proposal: accept to post it, reject to dismiss it. Several edits before the next close resolve to the final terms.

A catch-up surfaces only in the period where the change was made — rerunning an earlier period never pulls a later change backward.

An obligation or contract with recognized history can't be deleted. Deletion is blocked precisely because revenue already posted against it; cancel the contract instead (below).

A recorded term change is immaterial

Example: a prepaid's total was corrected by a few dollars, and the recorded change proposes a catch-up too small to be worth an entry.

Every term change on a started asset, schedule, or obligation is recorded, and the next close proposes its catch-up. When the difference isn't worth booking, reject the true-up proposal — rejecting dismisses the recorded change for good, so it stops resurfacing at every close. The item's detail keeps the record: the change, the computed difference, and the dismissal. Future months are unaffected either way — they already compute from the corrected terms.

A contract was cancelled or renegotiated away

Example: a customer terminates a multi-year contract, or you renegotiate it into a new one and the old contract should stop earning.

Set the contract's status to cancelled. Recognition stops immediately — no further periods are proposed for any of its obligations. Cancelling is a soft stop, not a delete: the contract and its recognized history stay intact for the record.

Cancelling also takes care of unwinding revenue that will never be billed. When the cancelled contract has recognized more than it billed — a contract asset, say a paid-ahead obligation the customer never took delivery of — the close of the month you cancelled in proposes the unwinding entry automatically, always as a review proposal, never auto-posted. The proposal reverses the recognized-but-unbilled balance, split across the contract's obligations, and its workpaper shows the position being unwound. Accept to post it; reject to keep the position — rejecting documents that judgment, and any adjustment you still want is then posted by hand.

Two edges stay a human call, and the workpaper says so:

• The cancellation month's own slice is not part of the unwind: once a contract is cancelled, that month's recognition is never proposed, so there is nothing posted to reverse. Whether any pre-cancellation service revenue should still be recognized is a judgment, noted per obligation and per contract.
• Contracts cancelled before a cancellation date was recorded propose nothing. Size and post that unwind by hand — the contract's schedule detail shows exactly what was recognized in each period, the support you need to document the manual entry.

If an obligation is missing its revenue or deferral account, its share of the unwind can't be proposed — the item flags the outstanding recognized-but-unbilled balance until the accounts are set and the item reruns (or the balance is adjusted manually).

A physical count found shrink

Example: the warehouse counts the floor and comes up short — a case of product is missing, or a spoilage batch was pulled from the shelf but never recorded.

The count itself is an ERP entry. Stock is the ERP's ledger of record, so you (or the warehouse) book the physical-count adjustment in the ERP — that's what brings recorded quantity and value back to what's actually on hand. Kraal doesn't post the count for you; posting stock is the ERP's job.

What the close does is pick the adjustment up. The next inventory close reads the corrected stock value, so the rollforward ties out against the lower balance and the reserve delta re-computes against the new aging — no separate entry to reconcile the count by hand. If the shrink was a genuine one-off, that's the whole story: book it, and let the close reflect it.

If counts keep coming in short — this product line shrinks every quarter — every shortage still gets booked in the ERP. The reserve never substitutes for the count adjustment: only the ERP entry corrects the overstated quantity and stock value, and skipping it leaves missing inventory on the books. What the recurring pattern tells you to do in addition is raise the reserve percentages (the aging-band rates, or the flat rate) in close configuration, so future months carry an obsolescence/shrink reserve that anticipates the loss before the next count confirms it. Book every count; use the rate to reserve ahead.

Inventory doesn't tie to the GL

Example: the inventory close comes back flagged for review — the general ledger's inventory balance and the ERP's stock valuation don't agree.

That flag is the inventory close item doing its job: it ties the GL out to stock and tells you when the two diverge beyond the configured variance threshold. The flag carries the difference and the accounts involved. It is a detector, not a correction — Kraal won't quietly move the ledger to match stock, because the right answer depends on why they differ.

The usual causes are postings that reached one side but not the other:

• A manual journal entry booked straight to an inventory account — someone adjusted inventory in the GL with no matching stock movement.
• A cost posted outside the stock system — a purchase, write-off, or reclass that hit the ledger but never ran through inventory, or the reverse.

Fix it at the source. Correct the entry in the ERP — reclassify the manual journal entry, or route the posting through the stock system so quantity and value move together — then re-run the inventory item. Because the rollforward and tie-out are computed fresh on every run, the next pass either clears the flag or shows a smaller, better-understood difference. The close item points; the ERP is where inventory gets corrected.

A posted entry was wrong

Example: last week's autoposted prepaid entry used the wrong total.

On the close item's posted entries, use Reverse. Kraal posts an exact correcting entry (every line swapped, customer/supplier references carried), dated into the next open period if the original month is locked. Once every entry on an item is reversed, the item can be re-run to post the corrected amounts — fix the schedule first so the re-run computes the right numbers.

Reversals only apply to entries Kraal itself posted, and each entry can be reversed once — the reversal is recorded on the item with a full audit trail.

An asset came from a previous system mid-life

Example: equipment imported with three years of depreciation already taken elsewhere.

Set the asset's opening accumulated depreciation and the months already depreciated (imports from ERPNext carry these automatically when the ERP has them; the import warns you when it can't). Kraal treats the opening balance as authoritative — those months are never re-proposed — and depreciates the remaining base over the remaining life. The rollforward ties without manual plugs.

A customer shouldn't be written off

Example: the aging shows a 130-day invoice, but the customer is in an active, documented dispute.

Use the aging's document hold or dispute action on that customer. The recorded flag is durable: automated write-off suggestions skip that customer on every future close (the skip and its reason appear in the item's detail), and the invoice stops counting as unreviewed aging work. One human judgment, respected by automation from then on.

Write-offs themselves are never automatic. Candidates appear as review proposals; a person accepts each one, and the posted entry carries the invoice reference so the receivable clears correctly.

Automation should pause

Example: you're investigating a discrepancy and don't want anything posting in the meantime.

Turn off the client's autopost in its automation policy (or use the assistant's autonomy pause). Nothing is lost — every item still computes its proposals and workpapers; they simply wait for review until you turn automation back on.

An error is found after approval or lock

Do not change an item inside an approved run and assume the old approval still applies.

• Approved but not locked — return or reopen the close for revision. Fix the source, reconciliation, schedule, or entry; rerun the affected work; then obtain fresh preparer, reviewer, and final approval as required.
• Locked — reopening is not self-serve. Contact your Kraal administrator or support with the client, period, and documented reason. Once reopened, make the correction and repeat the affected review and finalization steps.

Reopening preserves the previous workpaper, signoffs, package, and lock history instead of rewriting them. The prior client package becomes stale or superseded, and re-closing produces a new reviewed version. That makes it clear what was delivered originally, what changed, and who approved the correction.

The import said it skipped or warned about something

Import previews and results list every skipped asset with a reason (missing cost, missing dates, missing depreciation terms) and every warning (for example, depreciation history that couldn't be carried). Fix the source data in the ERP and re-import — already-imported assets are recognized and skipped, so re-importing is always safe — or add the missing details to the register by hand.

A step is asking for configuration you don't have

A close step that completes with a gap ("no schedules configured", "accounts not assigned") is telling you the client's facts say this domain exists but nothing is set up to compute it. Either add the missing configuration in Close Prep, or correct the client's profile if the domain genuinely doesn't apply. Gaps are prompts, not failures — the rest of the close continues around them.

---

If a situation isn't covered here, the item's detail view always shows what Kraal did and why — proposals, skips with reasons, and workpapers — which is the starting point for any correction conversation with support.