G/L Open Entries use cases

An open entry – also known as an open item – is a ledger entry (a transaction) that hasn't yet been fully settled or reconciled. In Microsoft Dynamics 365 Business Central, for example, a customer ledger entry is open if the invoice hasn't been fully paid, and a vendor ledger entry is open if the bill hasn't been fully settled. Once a transaction is fully matched with and reconciled against an invoice or credit note, the entry is closed.

The G/L Open Entries module extends this logic to G/L accounts, meaning that you can make any G/L account – such as a transit or clearing account – work the same way, tracking individual entries as open until they're matched and applied. The module is particularly useful for balance sheet accounts, whose balances carry forward from year to year.

In standard Business Central, every G/L account shows you a balance, but not what that balance consists of. For a busy balance sheet account like a VAT settlement account, a prepaid expense account, or an employee expense clearing account, many individual transactions flow in and out over time. At any given moment, and especially at year-end, you need to determine which of these entries are still unresolved, and why. Without G/L Open Entries, the typical approach is to export the account's ledger entries to a spreadsheet and then manually identify which debits and credits cancel each other out – a process that takes time, invites mistakes, and must be repeated from scratch every time you need to reconcile the account.

With the G/L Open Entries module enabled, a remaining amount is displayed for each G/L account entry. When you apply an entry against one or more matching entries, both sides are settled and removed from the list of open entries. What stays visible is exactly – and only – what the balance actually consists of.

Use case 1: VAT settlement

At the end of each VAT period, the VAT department nets output VAT (collected from customers) against input VAT (paid on purchases) and transfers the result to a VAT settlement account. The balance in that account represents the amount owed to – or refundable from – the tax authority. Once the payment is made, the account should net to zero.

Example

Bemærk

Real-life VAT settlement accounts can be extremely complex, so the following example is simplified but illustrative.

Over five months, your company's VAT settlement G/L account accumulates the following entries:


DateDescriptionDebit (EUR)Credit (EUR)Balance (EUR)
28 FebFebruary VAT settlement3,840.003,840.00
12 MarPayment – February VAT3,840.000.00
31 MarMarch VAT settlement2,760.002,760.00
14 AprCorrection – March VAT (input VAT reclassification)340.003,100.00
19 AprPayment – March VAT3,100.000.00
30 AprApril VAT settlement4,580.004,580.00
08 MayPartial payment – April VAT2,000.002,580.00
31 MayMay VAT settlement1,950.004,530.00
12 JunTax authority credit – prior period760.003,770.00
18 JunPayment – April VAT (remainder)2,580.001,190.00

This is what the G/L account would look like without the G/L Open Entries module. The current balance is €1,190. But what exactly does that consist of – and is it correct? To answer these questions, the bookkeeper has to reconstruct what happened entry by entry:

  • February was settled cleanly: the €3,840 settlement matches the €3,840 payment on March 12.
  • March was slightly more complex: a supplier invoice had been posted with the wrong VAT code. The correction entry on April 14 added €340 to the original €2,760 settlement, bringing the total to €3,100. The combined amount was paid on April 19.
  • April's large settlement of €4,580 was paid in two instalments: €2,000 on May 8 and €2,580 on June 18. But by the time the second instalment was posted, the May settlement had already appeared on the account – so the June payment of €2,580 is sandwiched between two unrelated entries, making it easy to misread as partial payment of May rather than the remainder of April.
  • May's settlement of €1,950 was partially offset by a €760 credit from the tax authority for a prior-period over-declaration. Because the credit is labelled "prior period", it's not immediately obvious whether it relates to April or May – and therefore whether April is actually fully settled, or whether the €1,190 balance represents one outstanding amount or two.

This is the core problem: the balance is probably correct, but reconstructing what it consists of requires reading every line and holding multiple threads in mind simultaneously. In practice this work is done in a spreadsheet and has to be repeated from scratch each time the account is reconciled.

The same example using G/L Open Entries

With G/L Open Entries enabled, each VAT period's entries are applied to one another as they're settled. February, March, and April are all closed: the April 14 correction is applied together with the original March settlement and the March payment, so all three entries close as a group. The two April payments are applied against the April settlement and likewise close together. The open entries list then shows only what remains unresolved:


DateDescriptionDebit (EUR)Credit (EUR)Remaining Amount (EUR)
31 MayMay VAT settlement1,950.001,190.00
12 JunTax authority credit – prior period760.000.00

The picture is unambiguous. May VAT is outstanding at €1,190: the original €1,950 liability, reduced by the €760 tax authority credit that has been applied against it. The credit's Remaining Amount is zero, confirming it has been accounted for and isn't floating unmatched. April doesn't appear at all, confirming that it's fully settled despite the split payment and the interleaved entries.

When the May payment arrives, the bookkeeper applies it against the open settlement entry, the Remaining Amount drops to zero, and the account is clear. If the auditor asks for a reconciliation, the bookkeeper exports the open entries list directly – no spreadsheet required.

Use case 2: Employee corporate card clearing

Many companies issue corporate cards to employees for travel and business expenses. When an employee makes a purchase, the card transaction is automatically posted to a transit G/L account, such as an employee expense clearing account. Once the employee's expense report is approved and posted, the actual cost moves to the relevant expense account, and the offsetting credit returns to the clearing account, canceling the original card transaction.

A single expense report often covers multiple card transactions. For example, a business trip might include a hotel, train tickets, and a taxi, all settled by one report posting. When entries from several employees accumulate in the same account over the course of a month, alongside the occasional correction or reversal, determining what the closing balance consists of becomes a significant manual effort.

Example

Bemærk

Real-life expense clearing accounts can be extremely complex, so the following example is simplified but illustrative.

In July, three employees use corporate cards for business travel and expenses. By month-end, the employee expense clearing account contains the following entries:


DateDescriptionDebit (EUR)Credit (EUR)Balance (EUR)
03 JulEmployee A – hotel, client visit380.00380.00
03 JulEmployee A – train, client visit94.50474.50
08 JulEmployee B – client dinner215.00689.50
10 JulEmployee A – conference registration750.001,439.50
14 JulExpense report: Employee A, 3 Jul (hotel + train)474.50965.00
15 JulEmployee B – airport taxi47.801,012.80
17 JulEmployee C – hotel, Munich520.001,532.80
17 JulEmployee C – meals, Munich63.401,596.20
18 JulExpense report: Employee B (dinner + taxi)262.801,333.40
21 JulEmployee A – software license (posted in error)299.001,632.40
24 JulReversal: software license posting299.001,333.40
25 JulExpense report: Employee C (hotel + meals)583.40750.00
28 JulEmployee B – flight to London618.001,368.00
31 JulExpense report: Employee A, conference750.00618.00

The closing balance is €618.00. Identifying what that represents requires working through all 14 entries:

  • Employee A's hotel (€380.00) and train (€94.50) were settled together by a single expense report on July 14 (€474.50). One credit covers two debits, so they can't be matched one-to-one.
  • Employee B's dinner (€215.00) and airport taxi (€47.80) were similarly combined into one expense report on July 18 (€262.80).
  • A software license of €299.00 was posted to the clearing account in error on July 21 and reversed on July 24. The two entries cancel each other out, but they add noise and must be identified and confirmed as intentional before they can be set aside.
  • Employee C's hotel and meals were settled by a single expense report on July 25 (€583.40), again combining two debits under one credit.
  • Employee A's conference registration (€750.00 from July 10) was settled by an expense report on July 31 – three weeks after the original transaction.
  • That leaves Employee B's London flight (€618.00 from July 28) as the only unmatched entry. But reaching that conclusion requires accounting for every other entry first.

None of this is visible in the €618.00 balance. Without the G/L Open Entries module, the bookkeeper exports the account to a spreadsheet and works through the matching manually – a process that must be repeated every time a mid-month check is needed.

The same example using G/L Open Entries

With open entries enabled, each card transaction is applied against its matching expense report credit as reports are posted. When a single expense report covers multiple transactions (as with Employee A's and Employee B's reports), all the relevant debits and the combined credit are applied as a group and closed together. The error entry and its reversal are applied against each other and likewise disappear from the open list.

By month-end, the open entries list contains a single entry:


DateDescriptionDebit (EUR)Credit (EUR)Remaining Amount (EUR)
28 JulEmployee B – flight to London618.00618.00

Employee B's flight is the only unresolved item. The bookkeeper doesn't need to examine any other entries to confirm this – they're simply not there. When Employee B's expense report is posted and applied, the Remaining Amount drops to zero and the account clears.