Hold reasons
A held entry could not be built. It is kept with everything it needed and replayed once the obstacle is gone. Background in hold, don't drop.
Why entries are held
| Reason | What it means | What clears it |
|---|---|---|
| No accounting connection | Nothing is connected, so there is nowhere to post | Connect a provider |
| Missing ledger configuration | A required account is not mapped | Map the account |
Both are configuration, and both clear for every waiting entry at once — not one at a time.
What can be held
| Entry | Comes from |
|---|---|
| Goods-receipt valuation journal | Receiving a delivery |
| Supplier bill | Recording a supplier invoice |
COGS entries and count variances behave similarly but are kept as subledger records, with their account resolved when the configuration allows.
One entry per problem
A re-attempt against the same goods receipt or supplier invoice updates the existing held entry rather than adding another, with the current reason. A recurring obstacle shows once.
How a held entry is released
Two routes, and they share the same path:
- The nightly sweep re-attempts every held entry.
- A live attempt for the same thing.
Whichever gets there first clears the hold. There is no separate replay action, and you do not need one.
What the queue looks like as you configure
Falling on its own. Each account you map releases every entry waiting on it, so the count drops in steps rather than one row at a time.
A stack of issues immediately after connecting is the normal starting state, not a problem to work through individually.
Not the same as a failed post
A held entry was never sent. A failed post was sent and rejected. Recovering a held entry is not possible and would achieve nothing — see the three queues.