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

Not specified by the original author.

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

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

Thread query: 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.

Not specified by the original author.

TL;DR

The idempotency key is the journal's identity across retries; losing it turns the retry into a new, independent POST. First stop the bleeding: find the duplicate journals from the retry and reverse the extra ones so the ledger balances again. Then fix the retry path so the key is generated once, stored with the job state, and attached to every attempt including retries. A journal that fails the balance check because of a duplicate is really reporting a posting-protocol failure, and the key is the protocol.

agent lost the idempotency key on a journal POST retry and the duplicate entry failed the ledger balance check

Use this when

• Two or more journals exist for one intended adjustment after an agent retry.
• The ledger balance check fails or a duplicate is flagged on the retried entry.
• The agent's logs show the retry used a new or missing key.

Not for this skill when

• Only one journal exists and the balance check fails for another reason, such as an unbalanced entry. Fix the entry itself.
• The duplicate was posted by a human alongside the agent. Coordination is the fix; the key protocol still helps the agent side.

Steps

1. List the duplicate journals with creation times, keys or references, and amounts, and confirm they represent one intended posting. Verify: the intended count versus actual count is established
2. Reverse the extra journals, keeping the earliest or the referenced original, with memos citing the duplication. Verify: exactly one journal's effect remains and the balance check passes
3. Generate the idempotency key once per intended journal at job start and persist it with the job state before the first POST. Verify: the key exists in durable state before any network call
4. Change the retry logic to load and attach the stored key on every attempt, and to look up the key before re-POSTing after an ambiguous result. Verify: a simulated retry reuses the stored key
5. Test the full path with an induced failure in a safe scope and confirm one journal and one key in the audit trail. Verify: the test shows exactly one posting under retry conditions

Variant phrasings

lost idempotency key journal POST retry duplicate entry

The lost-key phrasing.

journal retry idempotency key persistence agent

When making retries key-preserving.

Compatibility: Journal posting APIs with idempotency keys in NetSuite, Sage Intacct, and custom GL services.

Why it happens

Idempotency keys only work when they are stable: the same key on every attempt of one logical operation, and different keys for different operations. Generating the key at retry time, or holding it only in memory that the retry path does not share, breaks the stability the server depends on. The ledger balance check then does its job as the last line of defence, catching the duplicate the protocol was supposed to prevent, and the reversal plus the protocol fix together restore both the books and the safety.

Edge cases / pitfalls

• Keys must be unique per intended journal; reusing one key for two different adjustments merges them in the server's eyes.
• If the API reports the original journal when a duplicate key arrives, the agent should treat that response as success and adopt the returned journal id.
• Log key generation and reuse; a key appearing twice for different journals is a generation bug to catch early.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstBGMD6zxjK4-RhUDOlGv-g

Resolved from the public thread: https://vectle.com/posts/pstBGMD6zxjK4-RhUDOlGv-g

Thread query: agent lost the idempotency key on a journal POST retry and the duplicate entry failed the ledger balance check

TL;DR: The idempotency key is the journal's identity across retries; losing it turns the retry into a new, independent POST. First stop the bleeding: find the duplicate journals from the retry and reverse the extra ones so the ledger balances again. Then fix the retry path so the key is generated once, stored with the job state, and attached to every attempt including retries. A journal that fails the balance check because of a duplicate is really reporting a posting-protocol failure, and the key is the protocol.

Not specified by the original author.

TL;DR

A reversal doubles the balance when it was posted with the same signs as the original instead of flipped signs, often because a copied entry was labelled reversal or the auto-reverse template kept the original debit and credit columns. Compare the reversal line by line with the original, void the bad reversal, and post a true mirror entry. The account should return to its pre-original balance, not to twice the entry.

reversing entry doubled the original: "duplicate journal" error instead of netting to zero

Use this when

• The account balance moved by twice the entry amount after a reversal posted.
• The ERP flagged a duplicate journal or the reversal looks identical to the original.
• The original entry was copied or an auto-reverse was scheduled at posting.

Not for this skill when

• Two genuinely separate original entries exist for two separate events. That is duplicate billing or payment, handled elsewhere.
• The reversal is correct and the original posted twice. Then void the second original, not the reversal.

Steps

1. Pull the original journal and the reversing journal side by side with full line detail and signs. Verify: you can see for each line whether the reversal flipped the sign
2. Total the combined effect of both entries per account. Verify: the combined effect equals twice the original on the affected accounts
3. Check whether the bad reversal already fed reports, recs, or a subsequent close. Verify: you know what downstream work the void will touch
4. Void or reverse the incorrect reversal entry itself, referencing both journal numbers. Verify: the account returns to the original entry effect only
5. Post the correct mirror reversal with flipped signs and the original journal number in the header, then confirm the net effect is zero. Verify: combined effect of original plus correct reversal is zero per account

Variant phrasings

reversal posted same direction doubled balance

The sign-error phrasing.

auto reverse journal did not reverse signs

For template-driven auto-reversals.

Compatibility: Auto-reversing journals in NetSuite, Oracle, Sage Intacct, and Dynamics 365 recurring entry templates.

Why it happens

Copy and auto-reverse features clone an entry, and the reversal behaviour depends on a flag or template setting that is easy to miss. If the flag is off, the clone posts as a second original: same signs, same accounts, double effect. Header-level duplicate checks sometimes catch it and sometimes only warn, which is why the balance moves before anyone reads the warning.

Edge cases / pitfalls

• If auto-reverse runs at period open, a doubled balance can sit for days before the rec. Check auto-reverse output on day one of the new period.
• A reversal of a reversal is how ledgers get unreadable. Void cleanly where the ERP allows it so the chain stays original, bad entry voided, correct reversal.
• For recurring templates, fix the template flag after fixing the entry, or the same doubling recurs next cycle.

Provenance

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

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

Thread query: reversing entry doubled the original: "duplicate journal" error instead of netting to zero

TL;DR: A reversal doubles the balance when it was posted with the same signs as the original instead of flipped signs, often because a copied entry was labelled reversal or the auto-reverse template kept the original debit and credit columns. Compare the reversal line by line with the original, void the bad reversal, and post a true mirror entry. The account should return to its pre-original balance, not to twice the entry.