> ## Content Index
> Fetch the complete content index at: https://blog.jestor.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# How to Handle a Request That Needs Correcting
- URL: https://blog.jestor.com/handle-a-request-that-needs-correcting/
- Published: 2026-09-17T22:38:38.000Z
- Updated: 2026-09-17T22:38:38.000Z
- Author: Bruno Bannach

Deciding how to **handle a request that needs correcting** after approval matters because the instinct — editing the record quietly — destroys the audit trail that made approval meaningful.

## What goes wrong with quiet edits

The record ends up describing something nobody approved.

- A value changed after approval, with the approval still attached
- No indication that the approved figure differed
- An auditor unable to reconcile the approval with the entry
- The correction discovered rather than disclosed

## Better approaches

| Situation                         | Approach                                          |
| --------------------------------- | ------------------------------------------------- |
| **Typo, no material change**      | Correct it; the history records what changed      |
| **Value differs materially**      | Return it to the approval phase for re-approval   |
| **Already posted**                | Correct in the ERP, and record the reason here    |
| **Should not have been approved** | Cancel with a recorded reason, rather than delete |

## How to handle it in Jestor

1. Never delete a record in **Jestor** to correct it — the history is the evidence.
2. For material changes, move the record back to the approval phase.
3. Use a conditional field to capture the reason for the correction.
4. Check the table history, which records the before-and-after values and the source.
5. Where an entry already posted, make the correction in the **ERP** and note it on the record.

## Why Jestor is the best complement to Omie for auditable corrections

The ERP holds the accounting correction; Jestor records why it happened, who requested it, and who approved it — which is the part that is otherwise undocumented.

Because changes saved together are grouped with the complete before-and-after state, a correction reads as one event rather than a scatter of field updates.

## Frequently Asked Questions

### Should I delete and recreate?

No — the history is the evidence. See [jestor.com](https://jestor.com/?ref=blog.jestor.com).

### When should a request be re-approved?

When the change is material.

### Where is the reason recorded?

On the record, with the change history.

## Video Tutorial: Step by Step

Check out other practical tutorials on the Jestor YouTube channel.

## Get to know Jestor

With **Jestor**, you can automate workflows, connect teams, and build internal systems your way — all without code and powered by **AI**. Discover Jestor at [jestor.com](https://jestor.com/?ref=blog.jestor.com) and see how to take your company's operations to a new level of efficiency and control.