agent retried a failed journal-entry POST and double-posted the adjustment to the GL

TL;DR

A POST that times out is ambiguous: the journal may have posted while its response was lost. Retrying blindly creates the duplicate. First reverse the proven duplicate journal, keeping the original. Then rebuild the posting flow: send a unique idempotency key with every journal creation, and on any ambiguous failure, query the GL for that key or reference before deciding to retry. A retry should be a lookup first and a POST only when absence is proven.

agent retried a failed journal-entry POST and double-posted the adjustment to the GL

Use this when

• Two identical adjustment journals exist in the GL from one agent action.
• The first POST attempt reported a timeout, network error, or no clear result.
• The agent's retry logic re-POSTs on any failure without checking state.

Not for this skill when

• Two similar journals were intentionally posted for two entities or periods. Verify intent from references before reversing anything.
• The duplicate came from a user also posting manually. Process coordination is the fix, though the same state-check discipline helps.

Steps

1. Identify the duplicate pair by amount, accounts, memo, and creation source, and confirm which is the original by timestamp and audit trail. Verify: the pair and the keeper are established from the audit log
2. Reverse the duplicate journal in full with a memo citing the original journal and the double-post cause. Verify: the GL effect now equals one adjustment only
3. Add an idempotency key to every journal creation call, derived from the job and adjustment identity, stored with the job state. Verify: the key is sent on the initial call, not invented at retry time
4. Change failure handling: on an ambiguous POST result, query for the idempotency key or the unique reference, and only re-POST if the query proves absence. Verify: a simulated timeout resolves by lookup, not by duplicate POST
5. Run a controlled test with an induced timeout in a sandbox or on a trivial entry and confirm exactly one journal results. Verify: the test produces one journal and a clean audit trail

Variant phrasings

agent double posted journal retry no idempotency

The retry-duplicate phrasing.

journal POST timeout ambiguous result duplicate entry

When handling ambiguous outcomes.

Compatibility: Journal creation APIs in NetSuite, Sage Intacct, QuickBooks, and custom GL services with idempotency support.

Why it happens

Distributed systems cannot distinguish a lost request from a lost response, so a timed-out POST carries genuine uncertainty. Humans resolve it by looking before re-sending; naive retry logic skips the looking. Idempotency keys move the guarantee into the API: the server itself refuses the second creation with the same key. Without keys, a state query before retry is the minimum safe pattern, and every automated poster of financial entries needs one of the two.

Edge cases / pitfalls

• Reversing the duplicate promptly matters because downstream recs and reports consume the doubled balance within hours.
• If the API lacks idempotency support, a unique reference field the query can search is the fallback key; generate it before the first attempt.
• Log the ambiguity when it happens. A journal saved by a lookup after timeout is a success story the team should see, to trust the pattern.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_nxjWc9s5qmNq5iDY2FH4pg