Skip to content
PlaidCloud

Workday Financials: Post Journal Entry

Description

Section titled “Description”

Posts accounting journals to Workday Financials over your Workday Financials connection, routed through PlaidCloud’s shared ERP write pipeline. The step takes a header table (one row per journal entry) and a lines table (one or more debit/credit rows per entry), and calls Workday’s Submit_Accounting_Journal SOAP operation for each entry. Validate Only builds and checks every entry without a ledger claim and without posting; an optional result table records the outcome of each entry.

Configuration

Section titled “Configuration”

Connection

Section titled “Connection”
  • Workday Connection — the Workday Financials connection to post through.

Data

Section titled “Data”
  • Header Table — one row per journal entry: journal_id (your entry identifier, required), company (required), ledger (required), accounting_date, memo.
  • Lines Table — one or more rows per journal_id: ledger_account, debit, credit, and any worktag (cost center, project) columns your journals require.
  • Result Table — output table id: one row per entry with journal_id, natural_key, confirmation_id, status (posted/validated/error), message.
  • Validate Only — checked by default. Preflight only; no ledger claim, no post. A step configuration that omits this field entirely — for example one authored through the REST API, MCP, or a workflow bundle import — also defaults to Validate Only rather than a live post.
  • Continue On Error — checked by default. Keeps posting the remaining entries after one fails; unchecked stops the batch at the first failure.

How Posting Works

Section titled “How Posting Works”

PlaidCloud calls Submit_Accounting_Journal for each entry and polls its Workday business-process status until it reaches a terminal state — accounting for a Submit Accounting Journal business process that routes through approval steps before an entry is actually posted. An entry is only reported posted once that terminal state is confirmed — an entry that’s submitted but stuck pending approval stays quarantined (not reported posted, not silently dropped) rather than being recorded as success on the strength of the submission merely being accepted.

Correcting a Posted Entry

Section titled “Correcting a Posted Entry”

This step never deletes or rewrites a posted journal. To correct one, post a new entry with debits and credits swapped against the original — a posted reversing entry — rather than editing the original in place.

Capability Limits

Section titled “Capability Limits”

| Limitation | What it means | |—|—|| Business-process approval adds latency | An entry routed through an approval step stays pending until approved in Workday; the terminal-state poll waits for that. | | Reversal is a new entry, not an in-place edit | Corrections post a new debit/credit-swapped reversing entry. There is no void or delete of an already-posted entry. |

Section titled “Related”