General Ledger Entries
GETTable: G/L Entry
Read-only posted G/L entries. This mirrors Microsoft's standard General Ledger Entries feed and adds one column of its own, integrationId, so external systems can reconcile posted entries against their own key. There is no write surface. Entries are created only by posting.
Reconciling against what you posted
The integrationId here is not something you set on this endpoint. It is stamped onto the entry at post time by the journal post handler, carried over from the journal line eOne integration posted, and it is the key of the document rather than of a line. Every entry one document produces carries the same value, so filtering on it returns that document's entries and nothing else.
It has to be the document rather than the line: posting aggregates lines into entries by posting group, so one entry can be the sum of several lines and one line can feed several entries. There is no line to point at. Where you do want line detail, read it from journal lines or processed documents.
GET/generalLedgerEntries?$filter=integrationId eq 'ORDER-1042'
integrationId is filled for entries posted from a staged eOne document (payments, refunds, credit memos, invoices, expenses, bank/G-L entries) and for entries from standard sales and purchase invoice and credit-memo posting where the document carried an integrationId. Entries from any other process - item journals, transfers, warehouse postings, or anything posted by hand - have it blank, so an empty result is normal for those.Grouping and tracing entries
Beyond the standard shape, this feed exposes reconciliation/trace columns: transactionNumber groups every entry written by a single posting, and sourceCode/sourceType/sourceNumber identify the process and the party behind the entry.
Amount and account fields
Alongside the separate debitAmount/creditAmount, a single signed amount is exposed (positive = debit) so callers do not have to derive it. accountId is a res resolver: G/L Entry stores only the account number, so the endpoint looks up the matching G/L Account and returns its SystemId for callers that key accounts by GUID.
Global dimensions surface as shortcutDimension1Code/2Code; 3Code..8Code are populated for entries posted through this extension's journal API. See dimensions.
Dimensions
shortcutDimension1Code and shortcutDimension2Code are Business Central's own global dimensions and are always correct. Dimensions 3 to 8 are read through dimensionSetId, which is where Business Central keeps them.
This feed used to publish shortcutDimension3Code..8Code from columns of its own. They were only ever filled for entries posted through this app's journal engine that also carried an integration id, so they were blank on everything from standard sales and purchase posting, and the storage has been removed rather than left looking like a slicing surface that mostly returned nothing.
Tracing an entry back to its document
integrationId is the whole of what this extension adds to G/L Entry, and that is deliberate. G/L Entry is the most heavily written table in Business Central, so every stored column is paid for on every posting, forever.
To go from a posted entry back to the eOne document that produced it, use the entry's documentNumber together with its postingDate. That pair is the supported handle:
GET/processedDocuments?$filter=postedDocumentNumber eq 'PS-INV-10231' and postedPostingDate eq 2026-08-31
In the Business Central client the same journey is Find entries on the eOne Processed Documents page, which opens the standard Navigate view for that document.
processedDocumentId column on this feed, and there will not be one. The processed document is reachable by document number and posting date, so a second stored key on the ledger would buy a shorter query at the cost of a column on every G/L entry ever written. If you are waiting for one, use the filter above instead.