Posting Error Log

The Posting Error Log is the list of documents that automatic posting tried to post to the general ledger and could not. It keeps one entry per document with the reason, so a failure is not lost and you can fix it. Entries come from the Auto-post synced documents settings in Finance. A background job posts invoices, credit notes, bills, expense vouchers and journals for you. When a post fails, the job records the reason here, tries again later and marks the entry Resolved once the document posts.

Overview

Each entry names one document: its type (Source Entity Name), its number (Document Number), its company (Partner Account) and branch. It also holds the most recent error text, how many attempts have failed and when the first and last attempts happened. A Status of Pending means the document is still unposted as far as the log knows. Resolved means a later automatic attempt posted it.

The log covers automatic posting only. When you click a posting action on a document yourself and it fails, the error is shown on screen straight away and nothing is added to this log.

When to use it

• Daily or weekly, when automatic posting is switched on: check for Pending entries, so synced documents don't sit unposted.
• When a synced invoice or bill is missing from the ledger: look up its number here to see why it did not post.
• Before month-end close: make sure every document dated in the month has posted (see Fiscal periods and period close).
• After you change the posting user or a company's setup: confirm that the failures it caused have cleared.

How xMatix handles it

• Who writes entries. Only the automatic posting job writes entries. It runs every 15 minutes for a tenant that has switched on at least one document type and set Only documents created on or after (yyyy-MM-dd, UTC). Each run posts up to 50 documents. A larger backlog clears over the next runs.
• One entry per document. A failure creates an entry with Attempt Count 1. If the same document fails again while its entry is Pending, the job updates that entry: the count goes up by one, Last Attempt Utc moves on and Error Message is replaced with the newest reason. First Failed Utc keeps the time of the first failure.
• What counts as a failure. A failure is either a posting action that stops with an error, or an action that completes while the document still reads as unposted. The second case gives the message "The … action completed but the … is still not posted (nothing to post — e.g. a zero-value document — or GL posting is not enabled for its company)."
• Retry timing. A failed document is retried as soon as it changes, which means an edit to its header or to any line after the last attempt. It is then posted once it has been left unchanged for Wait after the last change (minutes). An unchanged document waits before its next attempt: 1 hour after the first failure, then 2, 4, 8 and 16 hours, and never more than 24 hours.
• Permission failures. A failure caused by the posting user and not by the document starts with [run as <user id>] (or [run as none]) in the error text. Examples are the user lacking a permission, or the document being hidden from that user. Such a document is retried as soon as the posting user changes, without waiting.
• Resolving. When a later automatic attempt posts the document, the entry becomes Resolved with the Resolution Note "Posted automatically by the auto-post sweep."
• Only the automatic job resolves entries. The job looks only at documents that are still unposted and not cancelled. If you post the document yourself, or cancel it, its entry stays Pending. Delete the entry once you have checked the document.
• No period-close gate. Close Period does not read this log, so Pending entries don't stop a close. Clearing them is part of your own month-end review.

Prerequisites

• The Finance product is licensed for your tenant. The automatic posting job does not run without it.
• Automatic posting is switched on for at least one document type, and the start date is set (see Configuration).
• To read the log, your security profile needs read access to Posting Error Log.
• To fix a document, you need edit access to that document type and permission for its posting action.

Procedure

Step 1 — Open the log

1. Open the Finance Setup app.
2. Under Books & Posting, open Posting Error Logs.

The All Posting Error Logs view lists Document Number, Partner Account, Name, Attempt Count, Purpose, Branch, Source Entity Name, Resolution Note, Created By, Created On and Updated On.

The shipped view has no Status column, so it lists Resolved entries next to Pending ones. An entry with no Resolution Note is still Pending. To filter properly, ask an administrator to add Status and Error Message to the view (see Configuration).

Step 2 — Read why a document failed

1. Select the entry's Name to open it.
2. Read the Details card: Error Message, Attempt Count, First Failed Utc, Last Attempt Utc, Purpose and Resolution Note.

The error text starts with Auto-post: followed by the reason. Times are in UTC. The record page has no buttons: it is for reading only.

Step 3 — Find the document

The entry does not link to the document. Use the Source Entity Name to find the screen, then search for the Document Number:

Step 4 — Fix the cause

Correct whatever the error names. Common examples are an inactive GL account, a missing party on a receivable or payable line, a closed period or a missing posting permission (see Common problems). Then choose one of these:

• Let the job post it. Save the fix on the document itself. Because the document has changed, the job tries it again on a run after Wait after the last change (minutes) has passed. The fix may be outside the document, for example reactivating a GL account or reopening a period. In that case the document only gets its next attempt when the back-off ends, unless you also edit and save the document.
• Post it yourself. Run the document's own posting action, for example Post General Ledger on an invoice. Then go to Step 5, because the entry stays Pending.

Once the job posts the document, the entry shows Resolution Note "Posted automatically by the auto-post sweep." and its status is Resolved.

Step 5 — Clear an entry that no longer applies

You might have posted the document yourself, cancelled it, or decided it should never post. In each case:

1. In the list, open the row's actions menu and select Delete.
2. Confirm.

The entry leaves the list. If the document is still unposted and posting is still switched on for its type, the job tries it again on its next run. If that attempt fails, the job creates a new entry.

Edit is shown in the row menu but opens the message "No form is set up for Posting Error Log". You cannot change an entry's status or note from the shipped screens. Don't use Clone on an entry either: a copied entry is not linked to any posting attempt.

Fields

Business rules

• Entries are created and updated only by the automatic posting job. There is one Pending entry per document at a time.
• Each repeat failure adds one to Attempt Count, refreshes Last Attempt Utc and replaces Error Message.
• An unchanged failed document waits 1 hour × 2^(attempts − 1) after its last attempt, up to 24 hours, before the next attempt. Changing the document makes it eligible right away, once Wait after the last change (minutes) has passed.
• If the error text carries a [run as …] stamp, the document is retried as soon as the posting user is different from the stamped user.
• A successful automatic post sets Status to Resolved and fills Resolution Note.
• Posting a document by hand, or cancelling it, leaves its entry Pending.
• Deleting an entry removes it from the log. Nothing else changes.
• The withheld-tax catch-up for customer receipts runs alongside automatic invoice posting. It does not write entries to this log.

Example

A distributor syncs its purchase bills from an accounting system. Its administrator has switched on Post synced Bills automatically with Only documents created on or after set to 2026-10-01.

1. On 20 October, bill BL-0458 from the supplier Sunrise Packaging syncs in at 10:05 UTC. It lands in the ledger with an expense line on GL account Freight Inward, which was made inactive last week.
2. Once the bill has been unchanged for the 30-minute wait, the next run tries to post it at 10:45 UTC. Posting stops, and the log shows a new entry: Document Number BL-0458, Source Entity Name Bill, Attempt Count 1. The Error Message reads "Auto-post: GL Account 'Freight Inward' is inactive. Please update the Posting Definition or journal line before posting."
3. The job tries again at about 11:45 UTC and fails. Attempt Count becomes 2, and the next attempt waits two hours.
4. The accountant reactivates Freight Inward at 12:10 UTC, then opens the bill, edits it and saves it so it counts as changed.
5. At about 12:45 UTC the bill posts. The entry's Resolution Note reads "Posted automatically by the auto-post sweep." and its Status is Resolved.

Training

Practice exercise

In a sandbox:

1. Ask your administrator to switch on Also post documents created in xMatix and Post synced Bills automatically, and to set Only documents created on or after to today and Wait after the last change (minutes) to 5.
2. Make a GL account inactive. Create a bill that posts to it for a company with GL Posting Enabled, and move the bill out of Draft.
3. Within about 20 minutes, open Finance Setup → Books & Posting → Posting Error Logs.

Expected result: one entry for your bill, with Source Entity Name Bill, Attempt Count 1 and an Error Message naming the inactive account. Reactivate the account and edit the bill. Within the next runs the entry shows the resolution note. Then switch the settings back off.

Quick reference

• Only automatic posting writes to the log. A failed manual post shows its error on screen.
• The shipped list has no Status column. A blank Resolution Note means Pending.
• Times on the entry are UTC.
• Fix the document and save it to get an early retry.
• Unchanged documents are retried after 1, 2, 4, 8 and 16 hours, and then every 24 hours.
• [run as …] in the error means the posting user is the problem, not the document.
• Posted it yourself? Delete the entry. It does not clear itself.
• Close Period does not check this log.

Permissions

The posting user also needs to be able to see the documents under your record-sharing rules. A document hidden from that user fails with a message that it "is not visible to the user it is posted as".

Configuration

All settings are in Setup → Feature Hub → Modules → Finance → Settings, group Auto-post synced documents:

Other settings that matter:

• GL Posting Enabled on the company's partner account. Documents of a company without it are never selected (see GL accounts).
• Make Status and Error Message visible. In Setup → Design Studio → Entities → Posting Error Log → Experience → Views, add Status and Error Message to All Posting Error Logs. You can also add a view that keeps only Pending entries (see Entity behavior).
• The Finance Mobile Dashboard has a Pending Posting Errors by Document table. It counts Pending entries by document type.

Common problems

"No user to post as" on every entry

No posting user could be found. Post as user (user id) is blank, and the sync profile that brought the document in has no sync identity. Set Post as user (user id) to a user who has the permissions in the Permissions table. Entries with this error are retried on the next run once the user is set.

"is not allowed to perform" or "has no security profiles"

The posting user lacks a permission. Give that user's security profile Update on the document type and the posting action, or set a different Post as user. The document is retried when the posting user changes. After you change the profile of the same user, edit and save the document to retry it straight away.

"is not visible to the user it is posted as"

Record sharing hides the document from the posting user. Widen the user's access to that company or branch, or choose a posting user who can see it.

"GL Account '…' is inactive"

A line or posting definition points at an inactive GL account. Reactivate the account, or change the posting definition or line, then save the document.

"Party Account is required on lines posting to a control account."

A line posts to a receivable, payable or other control account without naming the customer or supplier. Complete the party on the document and save it.

"Fiscal period '…' is Closed — posting is not allowed."

The document's date falls in a Closed or Locked period. Reopen the period with an approved Reopen Period, or change the document date, then save the document. See Fiscal periods and period close.

"… action completed but the … is still not posted"

The document has nothing to post (for example a zero-value document), or its company does not have GL Posting Enabled. Correct the document or the company setup. If the document should never post, delete the entry.

The document is posted but its entry still says Pending

Someone posted the document by hand, or it was cancelled. The automatic job no longer looks at it, so it can't resolve the entry. Check the document and delete the entry.

Common questions

Why can't I see a Status column?

The All Posting Error Logs view that ships with xMatix lists the document, company, branch, attempts and resolution note, but not Status or Error Message. Until an administrator adds those columns, use the Resolution Note column: an entry with no note is still Pending, and a resolved entry carries the note "Posted automatically by the auto-post sweep." To read the error itself, open the entry: Error Message is on its Details card. Adding the two columns, and a view that shows only Pending entries, takes an administrator a few minutes in the entity's Views settings.

Does a failed manual post appear here?

No. When you run a posting action on a document yourself and it fails, xMatix shows the error on screen at once, and you fix it while the document is open. The log exists for the background job, which has nobody watching it. That job is the only process that writes entries, so the log is a picture of automatic posting only. If a document you posted by hand has an entry from an earlier automatic attempt, that entry stays Pending until you delete it.

How often does xMatix retry a failed document?

The job runs every 15 minutes. A document you changed after its last attempt is tried on the first run after it has been left alone for Wait after the last change (minutes), which is 30 by default. A document nobody has changed waits 1 hour after its first failure, then 2, 4, 8 and 16 hours, and never more than 24 hours between attempts. It keeps being retried while it is unposted and posting stays switched on for its type. A failure caused by the posting user is retried as soon as the posting user changes.

Do Pending entries stop me closing a period?

No. Close Period changes the period's status without reading this log, so a month can be closed while documents dated in it are still unposted. If such a document is later retried, posting refuses it because the period is no longer open, and its entry shows a closed-period error. Review the log for documents dated in the month before you close it, as part of the checklist in Fiscal periods and period close.

Related topics

• Fiscal periods and period close
• Working with journals
• Bills
• Credit notes
• Expense vouchers
• GL accounts
• Sync health
• Posting Error Log — entity reference