agent overwrote last month's reconciliation file when the export filename reused the same date stamp

TL;DR

The agent did nothing exotic: it wrote this month's export to the same path as last month's because the filename contained a day stamp rather than the reconciliation period, and the run happened on the same day of the month. Recover first: check the storage platform's version history or trash, the agent's run artefacts, or regenerate last month's rec from the ERP's saved reconciliation, which usually persists even when its export file is gone. Then fix the naming contract so periods can never collide: include the period (year and month), the account and a run identifier in every export name, write to a period folder, and make the writer refuse to overwrite an existing final file. Treat the saved ERP reconciliation as the record and exports as copies, so a filename accident can never again destroy the only evidence of a close.

agent overwrote last month's reconciliation file when the export filename reused the same date stamp

Use this when

• A reconciliation export for last month was overwritten by this month's run from an agent or script.
• Filenames use generic patterns such as the run date, the word final, or the account name alone.
• The close evidence pack references the exported file rather than the system record.

Not for this skill when

• The ERP reconciliation itself was deleted or altered. That is a system record problem; restore from backup or audit data.
• The file was overwritten deliberately in a controlled revision with versioning on. That is normal document practice.

Steps

1. Stop the agent's export schedule for this account until naming is fixed, so the next run cannot overwrite anything else. Verify: the export job is paused and the remaining files are safe
2. Attempt recovery of last month's file: storage version history, recycle or trash, agent run artefacts, then regeneration from the ERP reconciliation. Verify: last month's rec content is recovered by one of the routes, or its loss is formally established
3. Verify the recovered file against the ERP's saved reconciliation for that period: balances, outstanding lists and difference. Verify: the recovered evidence agrees with the system record
4. Change the export naming to period, account and run identifier, write into period folders, and set the writer to fail on an existing final filename. Verify: a test export for the same period under a new run creates a new file instead of overwriting
5. Re-enable the schedule, note the incident and recovery in the close log, and confirm the evidence index points at the recovered file. Verify: exports resume safely and the close record is complete

Variant phrasings

agent overwrote last month reconciliation file same filename date stamp

The overwrite symptom.

reconciliation export naming convention period folder overwrite protection

The naming-contract phrasing.

recover overwritten reconciliation file version history regeneration ERP

The recovery-route search.

Compatibility: Agent and RPA export jobs writing to SharePoint, Google Drive, network shares or S3, fed by reconciliations in NetSuite, SAP, BlackLine, FloQast or spreadsheets.

Why it happens

Date stamps feel unique to the human who chose them, but a monthly job run on the same day produces the identical stamp every cycle, so the filename was only ever unique by accident of timing. File writes default to overwrite in most libraries, and agents do not pause to ask whether a same-named file might be last month's audit evidence. The collision is a naming-design flaw, and it stays latent until the run day aligns, which for monthly finance jobs is immediately.

Edge cases / pitfalls

• Version history retention is finite on many platforms; recover quickly and check retention settings for close folders.
• Read-only flags on finalised close files add a second line of defence beyond naming.
• Regenerated exports may differ in run metadata from originals; label them as regenerated in the evidence pack.

Provenance

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

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

Thread query: agent overwrote last month's reconciliation file when the export filename reused the same date stamp

TL;DR: The agent did nothing exotic: it wrote this month's export to the same path as last month's because the filename contained a day stamp rather than the reconciliation period, and the run happened on the same day of the month. Recover first: check the storage platform's version history or trash, the agent's run artefacts, or regenerate last month's rec from the ERP's saved reconciliation, which usually persists even when its export file is gone. Then fix the naming contract so periods can never collide: include the period (year and month), the account and a run identifier in every export name, w