Fixing a Wrong Department, Location, Project, or GL Code on an Invoice

1. Identify the stage: before approval, after approval, or after posting. 2. Before approval: edit the GL account or dimension directly on the invoice. 3. Revalidate: confirm field dependencies still hold after the change. 4. After approval: correct the value, then re-approve if policy or routing requires it. 5. After posting: create a reclassification entry in the ERP instead of editing the original. 6. Document: record what changed, who changed it, and why. 7. Prevent recurrence: apply defaults, templates, or dependency rules.

The simplest case is catching the error before the invoice is approved. The processor corrects the GL account, department, location, or project directly on the invoice and confirms the coded distribution still balances to the invoice total.

After changing a value, the reviewer revalidates field dependencies. Many coding fields depend on each other, so changing the entity or department can change which GL accounts or projects are valid. The corrected combination has to be one the ERP will accept.

When the error is caught after approval but before posting, the fix is still on the invoice, but it may carry an approval consequence. If the coded values, such as department or amount allocation, determined who approved the invoice, changing them can mean the invoice needs to be re-approved.

The reviewer corrects the coding and follows policy on re-approval. Documenting the change matters here, because an approved invoice that is altered should show what changed and who authorized the new coding.

Once an invoice has posted to the ERP, the original transaction is part of the books. The correct fix is a reclassification entry in the ERP that moves the charge from the wrong department, location, project, or account to the right one.

This is usually owned by the GL or controller team rather than the AP processor, because it is an accounting adjustment rather than an invoice edit. Re-keying the original posted invoice is not the right path, since the ledger already reflects it.

Coding errors have different owners depending on what is wrong. A keying mistake on a GL account or dimension is usually an AP correction. A question of which cost center, project, or entity should actually bear the charge is a business decision that belongs to the department owner or the controller.

Separating these matters because they are different problems. One is a data-entry fix. The other is a judgment about where the cost belongs, and sending it to the wrong owner slows the correction and blurs accountability.

Stampli supports correct coding by validating invoice data against ERP rules as it moves through the workflow, so coding errors surface before approval and posting rather than after. Stampli AI suggests the GL account, dimensions, entity, and period using ERP logic and validation, while all suggested entries remain subject to human review and approval before posting to the ERP.

Because Stampli mirrors the chart of accounts, entities, and dimensions from the ERP, field dependencies are enforced at the source. When a parent value changes, the valid options downstream update, which helps prevent the invalid combinations that cause failed exports.

Every change is captured in an immutable audit trail with full context, so a coding correction shows what changed, who changed it, and when. Defaults and reusable coding patterns reduce repetitive keying on recurring spend, which lowers the rate of coding errors over time.