Two users changed the same accounting record: resolve the version conflict

If an application says an invoice or supplier record changed while you were editing it, keep a record of your intended change and inspect the latest saved version. Repeatedly pressing save can obscure the conflict. The task is to decide which current values should remain and which new changes are still appropriate.

For example, one employee may correct a bill's department while another updates its payment terms. If each submits an entire older copy of the record, the later submission can restore the other field to its previous value. The edits need not target the same field to create a lost-update problem.

MDN documents HTTP If-Match as a conditional request using an entity tag to check the resource version. A failed condition produces a 412 response; the mechanism can help prevent an update from overwriting a change made after the original read. This is one supported web mechanism, not a claim that every accounting API implements it.

Ask the integration owner what the actual product uses: an entity tag, version token, lock or another documented approach. Identify which fields and operations the check covers. A timestamp shown on a screen is not necessarily a token that the server uses to reject stale writes.

Keep the version value associated with the record that was read. Do not replace it automatically with the newest token and resubmit the old complete object. That can satisfy the technical check while still discarding changes the user has not reviewed.

Build a short three-way comparison for the affected fields: what the editor originally saw, what is now stored, and what the editor intended to change. Identify who made intervening changes and why. Preserve the relevant audit history through authorized access rather than asking users to reconstruct it from memory.

Separate independent descriptive edits from changes with connected accounting consequences. A department correction and a due-date change may be reviewable together, while a changed amount, payment status or approval state may invalidate the proposed action. The responsible finance owner should decide the resulting business record.

If the record has already been posted, paid or otherwise progressed, follow the system's supported correction process. An edit that was appropriate for a draft can be inappropriate after that state changes. A concurrency check should prompt that review rather than become an obstacle to bypass.

Use the product's supported update method and keep the change limited to the intended fields where the interface allows it. Re-read after a further conflict instead of creating an unlimited retry loop. Assign persistent conflicts to an owner who can coordinate competing jobs or users.

After the update, inspect the stored result and any affected accounting output. Confirm that the other authorized changes remain present. Keep the final reference and approval evidence so the team can distinguish a resolved conflict from a request that merely stopped returning errors.

In an approved test environment, let two editors start from the same record, then save different changes in sequence. Verify that the stale update is detected or handled according to the documented design. Repeat a case where both editors change the same financially significant field and one where the record changes state between read and write.

The acceptance record should show what the user sees, what remains pending and how the final version is chosen. It should also establish that a failed attempt does not silently lose the editor's intended change or overwrite another person's approved work.