Accounting lists the posting records of your organisation: one record for each committed platform event, with what DALP did with it. DALP posts each final money event that the organisation's rule table maps, such as a trade settlement, a fee or a paid dividend, to the organisation's own Xero ledger as a manual journal, and the record says whether that journal posted, is waiting, or could not post and why.
Use the page to check what reached Xero and to send a record that failed back to be posted once you have fixed the cause. The page does not connect Xero or change the rule table, the account mapping or the posting policy: an administrator does both through the Platform API, as Post DALP events to a ledger describes.
The “Accounting” page shows the Xero connection state under the title, then the posting records table with its “Status” filter.
In the shot, the organisation has stored no accounting configuration yet, so Xero reads “Not connected” and the table reads “No postings yet”. Once the organisation posts, each row shows a record's event, status, amount, Xero journal and what happened to it.
Steps
Find the records that did not post
Open the Status filter in the table toolbar and choose “Failed”, “Not mapped” or “Not posted”. The table lists the newest records first, 25 to a page.
Read what happened
The What happened column says in plain words why the record is held back, such as “Xero refused the journal.” or “An account in the journal has no Xero account code.”, with the message of the last failure under it. Expand the row for the record's detail, including the “Last failure” in full and the journal lines DALP built.
Fix the cause
Fix what the record names before you retry it. A missing account code or rule is fixed in a new configuration version, and a refusal from Xero is fixed in Xero, for example by correcting the account there. A new configuration version decides every “Not mapped” record again on its own, so those records post on the next pass without a retry. Do not edit or delete the narration of a DALP journal in Xero, because DALP finds its journals by it: correct a posted journal with a new journal instead.
Select Retry posting
Open the row's actions menu and select Retry posting. The Console confirms “Queued to post again”, the record reads “Waiting to post”, and the “Retries” count in its detail goes up by one. The retry is not held for a second approver.
The posting job runs once a minute, so a retried record changes on its next pass, within about a minute. A “Not mapped” or “Not posted” record is decided again with the newest configuration version. A “Failed” record whose journal DALP already sent to Xero keeps that journal: when the last send was less than six minutes ago, DALP sends the same journal again as built. Otherwise DALP first looks the journal up in Xero, marks the record “Posted” when Xero holds it, and builds the journal again from the newest configuration version when Xero does not. So after a configuration fix, wait six minutes from the last send before you retry such a record.
Table columns
Each row is one posting record:
- Status shows the record's badge, from the table under Statuses.
- Event shows the journal narration with the event type under it, or only the event type when DALP built no journal.
- Amount shows the total of the journal's debit lines in the ledger currency, or a dash when DALP built no journal.
- Xero journal shows the start of the Xero manual journal id with a copy button. A record in a daily journal shows “Daily journal of” and the day, or “Daily journal 2 of” and the day for a supplementary journal of that day, with the Xero id once Xero accepted the journal. A record with no journal in Xero shows “Not in Xero yet”.
- What happened shows why the record is held back and the last failure message, or a dash when nothing holds it back.
With no records, the table reads “No postings yet” and “Money events appear here once the organisation stores an accounting configuration.”
Record detail
Expand a row to read:
- Source event: the
source_idof the committed event, which stays the same when the event is delivered again. - Received: the date and time DALP took the event in.
- Configuration version: the version that decided the record.
- Posting policy: “One journal per event” or “One journal per day”.
- Attempts: how many times DALP tried to post the record.
- Retries: how many times someone retried it.
- Xero organisation: the start of the id of the Xero organisation the record posted to, with a copy button.
- Last failure: the message of the last failure, from Xero or from DALP's own check.
- Journal lines: one row per line of the journal DALP built, with “Account key”, “Debit or credit”, “Amount” and “Description”. The account key is the organisation's own name for an account, which the account mapping turns into a Xero account code.
Statuses
Xero connection
The connection state sits beside the page title, next to the word “Xero”, and reads one of three badges.
- Connected: DALP can post, and “Last refreshed” gives the day DALP last refreshed the Xero grant.
- Needs reconnecting: Xero refused the stored grant, for example because someone removed the app's connection in Xero. Posting pauses until an administrator connects again.
- Not connected: the organisation has no Xero connection.
While the state is not “Connected”, the page adds “Records wait to post until an admin connects Xero.” When the state cannot be read, the page reads “The Xero connection could not be read.”
Xero connect outcomes
When an administrator connects Xero, Xero returns the browser to this page with the outcome, and the page shows a notice between the title and the table:
When Retry posting is unavailable
Retry posting works for a record that reads “Failed”, “Not mapped” or “Not posted” and still keeps its event data. For any other record the action is unavailable, and it says why:
- “A posted record cannot post again. Correct it with a new journal in Xero.” shows on a “Posted” record.
- “This record is already queued to post.” shows on a record that reads “Waiting to post” or “In a daily journal”.
- “DALP no longer keeps this event's data, so it cannot post again.” shows on a record whose event data is gone. DALP keeps a record's event data until 30 days after it reads “Posted” or “Not posted”, so only a “Not posted” record, or one whose data was gone before DALP copied it, loses it. Book such an event by hand.
Troubleshooting
Accounting is not in the sidebar
The entry appears under Business operations only for an organisation owner or a platform administrator with an active organisation. Roles and permissions lists the roles.
Every record reads Waiting to post
Check the connection state beside the title. While Xero reads “Not connected” or “Needs reconnecting”, DALP posts nothing and raises a “Xero connection needs attention” case. An administrator connects Xero again, as Connect Xero describes, and the waiting records post on the next pass.
A retried record failed again
The cause is still there. Read “Last failure” in the record's detail, fix the cause in Xero or in a new configuration version, then retry again. DALP also raises an “Accounting posting failed” or “Accounting event blocked” case for a record that cannot post, which your team works with its other operations cases.
Frequently asked questions
Can a retry post the same journal to Xero twice?
No. DALP sends each journal with an idempotency key and a narration marker. Within six minutes of a send it sends the same journal again, which Xero matches by the key. After that it looks the marker up in Xero first, and records a journal Xero already holds instead of posting it a second time. A “Posted” record cannot be retried at all. Correct a posted journal with a new journal in Xero.
Does a Not mapped record need a retry after a configuration fix?
No. A new configuration version decides every “Not mapped” record again on the next pass. Retry a “Failed” record once its cause is fixed, such as a journal Xero refused.
API routes
GET /api/ lists the records the table shows, and POST /api/ is the route behind Retry posting. GET /api/ reads the connection state. All three need a Console session, and an API key is refused. Read and retry posting records describes the calls and their errors, and the request and response shapes are in the Platform API reference.