Skip to content
PlaidCloud

S/4HANA: Post Journal Entry

Description

Section titled “Description”

Posts general ledger journal entries to SAP S/4HANA Cloud over your S/4HANA Cloud 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 submits each entry to S/4HANA Cloud’s JournalEntryBulkCreateRequest_In SOAP service. 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”
  • S/4HANA Connection — the S/4HANA Cloud connection to post through.

Data

Section titled “Data”
  • Header Table — one row per journal entry: journal_id (your entry identifier, required), company_code (required), document_date, posting_date, fiscal_year, ledger, header_text.
  • Lines Table — one or more rows per journal_id: gl_account, debit, credit, and any cost_center/profit_center dimension columns your ledger requires.
  • 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 submits each entry via JournalEntryBulkCreateRequest_In and polls for the corresponding JournalEntryBulkCreateConfirmation_Out message that reports the entry’s terminal processing state. An entry is only reported posted once that confirmation is received — an entry that’s accepted but whose confirmation never arrives 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 entry. 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 | |—|—|| Confirmation latency | The bulk-create service processes requests asynchronously; the terminal-state poll waits for the confirmation message rather than getting a synchronous result. | | 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. | | Dimension validation depends on your ledger setup | A cost object or dimension combination invalid for your account structure fails at S/4HANA’s own validation, surfaced as an error row rather than caught earlier by PlaidCloud. |

Section titled “Related”