Review ERP Post History

When a workflow posts to an ERP — a Sage Intacct or NetSuite journal entry, an SAP document — PlaidCloud records each post attempt in a durable, per-tenant ledger so the same document is never posted twice. ERP Post History is the read-only view over that ledger: every attempt and its live state, with the ERP’s own document number and timestamps, filterable by project.

It is complementary to the per-run result table a posting step writes: the result table is one run’s outcomes, while Post History is the standing record across every run and workflow, and it tracks each post through its full lifecycle rather than freezing it at the moment the run finished.

Note

Post History is read-only — it never changes a post or the ledger. It is available over the REST API and as an MCP tool; there is no separate screen to open.

What Each Post Shows

Each row is one document posted (or attempted) to one ERP environment on one connection:

Field	Meaning
project_id	The project the post was made from.
connection_id	The ERP connection used.
environment_id	The connection environment posted to (for example a sandbox versus production).
natural_key	The document’s business key, as the posting step derived it.
state	The post’s current lifecycle state (see below).
confirmation_id	The ERP’s own document number, once the ERP assigns one.
run_id	The workflow run that made the post.
submitted_at, created_at, updated_at	When the post was submitted, first recorded, and last changed.

The Lifecycle States

A post moves through these states as the ERP processes it:

State	Meaning
preflighted	Validated and claimed, not yet sent to the ERP.
submitted	Sent to the ERP; the outcome is not yet known.
pending	Accepted for asynchronous processing; awaiting a final result.
posted	Confirmed posted; confirmation_id holds the ERP document number.
rejected	The ERP declined the post.
in_doubt	The outcome could not be confirmed — needs a human to check the ERP directly before any retry.
reversed	A previously posted document was reversed.

Caution

An in_doubt post is exactly that — unknown, not failed. Confirm it in the ERP itself before deciding whether to act on it; never blindly re-run it.

Read the History

Scope every read to one project you can access. You need read access to that project — the same access the rest of your project work requires.

Over REST

GET /rest/v1/analyze/erp/write/history?project_id=<project>

Optional query parameters narrow the result:

Parameter	Effect
connection_id	Only posts made on this connection.
state	Only posts in this state (for example state=in_doubt).
limit	Page size (default 100).
cursor	The next_cursor from the previous page.

Results come back newest-first. When a page fills to limit, the response carries a next_cursor; pass it back as cursor to read the next page, and stop when next_cursor is null.

Over MCP

Call the erp_post_history tool with the same arguments — project_id (required), and optional connection_id, state, limit, and cursor. It returns the same rows, paged the same way.

Common Reviews

• Everything still in doubt for a project: state=in_doubt — the posts to confirm in the ERP by hand.
• What a specific run posted: read the project’s history and match on run_id.
• Whether a document actually posted: find its row and read state and confirmation_id.