Skip to main content
Metrics type: Key MetricsCategory: Ecommerce Platform
A real-time alert list of journals that hit Rejected posting status in Finance & Operations in the last hour. Each row is a posting that did not land in the GL.

At a glance

A live alert list of every journal whose PostingStatus flipped to Rejected in Finance & Operations within the last hour. A rejected journal is one that the system or a posting validation refused to commit to the General Ledger. Common causes are out-of-balance lines, a closed ledger period, a financial-dimension validation failure, or a missing main account. Each rejection is unbooked activity: the entry the user intended is not in the GL until someone fixes and re-posts it. This card is the real-time queue the finance systems team works to keep the ledger clean.

Calculation

Calculated automatically from your Microsoft Dynamics 365 data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.

Worked example

A multi-entity retailer on Finance & Operations with three legal entities (UK Retail Ltd, US Retail Inc, EU Retail BV) and a nightly batch that posts ecom settlement journals. The snapshot is taken at 09:14 on 12 Apr 26, covering rejections since 08:14. Four things to notice:
  1. Four rejections fired the alert at 09:14. The threshold is any rejection in the last hour, so the moment the nightly batch left these four in Rejected state the card lit up and the finance systems team had a worklist before the controller opened the ledger.
  2. The out-of-balance on GJ-2026-04-118 is the classic case. Debits and credits differ by $42.00, so F&O refused to post. The fix is to find the unbalanced line, usually a rounding or FX line the import dropped, and re-post. Until then the settlement is not in the GL and the bank reconciliation for US Retail Inc will not tie.
  3. GJ-2026-04-119 is a closed-period rejection, not a data error. The posting date fell inside a ledger period that was already closed. The journal is fine; it just needs re-dating into the open period or the period needs reopening if the close was premature. This row should be cross-checked against the Ledger Period Close Status card.
  4. GJ-2026-04-124 points at a chart-of-accounts gap. Main account 4055 does not exist in the EU Retail BV chart, so a line referencing it cannot post. This is a setup fix, not a one-off correction: until the account is created the same source feed will keep rejecting. Engineering is on the role list precisely because some rejections are integration or master-data defects rather than accounting mistakes.

Sibling cards merchants should reference together

This alert list is the front door to the ledger-integrity cluster. Pair it with these to find root cause and confirm the fix.

Reconciling against Microsoft Dynamics 365

Where to look in Business Central / Finance & Operations:
Finance & Operations: General ledger > Journal entries > General journals filtered to Status = Rejected Finance & Operations: System administration > Inquiries > Batch jobs (for batch-posted journals that failed) Finance & Operations: General ledger > Ledger settle and post > posting validation messages Business Central: Finance > General Journals (the closest equivalent; BC surfaces posting errors at post time rather than a persisted Rejected status)
In F&O, PostingStatus = Rejected is a real persisted state on the journal header, so the native General journals list filtered to Status = Rejected is the closest match to this card. The difference is that this card spans every connected legal entity in one queue and timestamps the rejection so you can see what failed in the last hour without flipping between companies. Why our number may legitimately differ: Cross-connector reconciliation: This is a finance-systems integrity card with no commerce-platform equivalent. Rejections that originate from ecom settlement or order-import feeds, however, often correlate with connector health: a malformed settlement journal frequently traces back to the same mapping defects surfaced on Power Automate Flow Failures (Ecom Integration). When a rejection spike coincides with a connector failure, treat the integration as the root cause rather than fixing each journal by hand.

Known limitations / merchant FAQs

What does PostingStatus = Rejected actually mean? It means F&O attempted to post the journal and a validation refused it, so nothing was written to the GL. The journal still exists in a rejected state and can be corrected and re-posted. It is not the same as a draft journal that was never submitted. What are the most common rejection reasons? Out-of-balance lines (debits do not equal credits), posting into a closed ledger period, a financial-dimension validation failure (a required dimension is blank or invalid), and a missing or blocked main account. Currency and posting-profile setup gaps also appear. Why is the window only one hour? Because this is an operational alert list, not a historical report. A one-hour window keeps it focused on what just failed so the finance systems team can react before the batch backlog grows. The full history of not-posted journals lives on the Open / Not-Posted Journal Entries card. A journal disappeared from the list before I fixed it. Why? Either someone else fixed and re-posted it (its status is no longer Rejected) or it aged past the one-hour window. Check the not-posted backlog card to confirm it was actually posted rather than just dropping out of the real-time view. Why is engineering on the role list for a finance card? Because a meaningful share of rejections are not accounting mistakes. Missing main accounts, dimension setup gaps, and malformed import journals are master-data or integration defects. Those need an engineer or systems owner, not a re-keyed correction. Does a rejected journal affect my GL revenue or AR figures? Not directly, because nothing posted. The risk is indirect: an unbooked settlement journal means the bank reconciliation will not tie, and an unbooked AR journal means a customer balance is wrong until it is fixed. The longer it sits rejected, the bigger the downstream reconciliation gap. Can Vortex IQ re-post the journal automatically? No. Vortex IQ surfaces the rejection, the reason, and the legal entity. Re-posting requires a human to correct the underlying issue and confirm the entry is right, because an auto-retry on a genuine data error would just fail again or post something wrong. Does this span all my legal entities? Yes. The card reads journal headers across every connected legal entity and presents one queue. This is the main advantage over the native F&O screen, which is typically viewed one company at a time.

Tracked live in Vortex IQ Nerve Centre

Journals Rejected at Posting (PostingStatus=Rejected) is one of hundreds of KPI pulses Vortex IQ tracks across Microsoft Dynamics 365 and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. Start for free or book a demo to see this metric running on your own data.