Bitta Commission guide

Reconciliation

Reconcile each posted accounting proposal with the G/L: build line-by-line comparisons, understand exception reason codes, record resolutions, and sign off at zero difference.

status: verified applies-to: 1.1.2.0rev: 1

A reconciliation proves that what Bitta Commission expected to post is exactly what reached the general ledger. For each posted accounting proposal, it compares the commission subledger lines with the linked G/L entries, line by line, and records every difference with a reason. A reconciliation can only be signed off at zero difference, and the signed-off evidence is immutable.

Before you start

  • The accounting proposal must be Posted. See Accounting and posting.
  • You need finance-wide access. Reconciliations are created, built and signed off by the Accountant role. Auditors can view them but cannot create, build or sign off.
  • If Require Reconciliation is on in Commission Posting Setup, reconciliation is part of your required posting control.

What is compared

Each posted proposal line is an accounting entry in the commission subledger, and each of those reproduces a commission balance movement. When the proposal posts, the app links the resulting G/L entries. A reconciliation compares three views:

Total Meaning
Source Total / Subledger Total The debit-side total of the commission accounting entries of the proposal.
G/L Total The debit-side total of the G/L entries of the proposal.

It also counts Matched Count and Difference Count, with Matched Total and Difference Total.

Create and build a reconciliation

  1. Open the posted proposal on Commission Accounting Proposal and choose Create reconciliation. If one exists already, it opens. Otherwise a new zero-tolerance reconciliation is created.
  2. Optional: while the reconciliation is in draft, choose Set comparison filters to limit it to certain G/L accounts (Account Filter), dimension sets (Dimension Filter) or currencies (Currency Filter). Blank compares everything. Filters cannot change after the build.
  3. Choose Build reconciliation. The app builds one comparison per accounting line and adds an exception for any G/L entry of the proposal that has no matching subledger line.
  4. Review the status: Matched when every comparison agrees, Exceptions when differences remain.

Read the comparisons

The Reconciliation Comparisons part lists every comparison:

Field What it shows
Expected Account No. / Actual Account No. The account the subledger expected, and the account the G/L entry used.
Expected Amount LCY / Actual Amount LCY / Difference Amount LCY The amounts and the difference.
Expected Posting Date / Actual Posting Date The dates on both sides.
Match Status Code MATCHED or EXCEPTION.
Reason Code Why a line is an exception: AMOUNT, ACCOUNT, POSTING-DATE, DIMENSION or CORRECTION.
G/L Entry No. The linked standard G/L entry. Choose G/L entry to open it.
Subledger Entry No. The commission balance movement this accounting line reproduces.
Resolution Reference The reference recorded when an exception was resolved.

The reason codes are checked in that order, so a line with both an amount and an account difference shows AMOUNT.

Resolve exceptions

A difference usually has a cause outside the commission app, such as a manual journal posted to the commission account or a changed dimension. Fix the cause in Business Central, for example with a correcting journal. Then:

  1. Select the exception line and choose Record resolution.
  2. Enter the reference that resolves it: a correcting journal number, a ticket or a short explanation.

The frozen comparison is not changed, and a line can be resolved only once. A matched line cannot be resolved.

WARNING

Recording a resolution does not allow sign-off while differences remain. Sign-off always requires unchanged evidence and zero differences.

Validate, refresh and sign off

  • Validate reconciliation reviews the current evidence, the exact G/L links and any unmatched differences, without changing anything.
  • Refresh comparison totals checks that the frozen comparisons still match the current accounting and G/L evidence and refreshes the unsigned totals. If the posting date, a G/L link or the document context changed, the refresh is refused. The original evidence is kept in the audit trail.
  • Sign off reconciliation records the approval when the evidence is unchanged and the differences are zero. The status becomes Approved, and Evidence Hash and Approved At are stored.

Reconciliation statuses: Draft, Running, Matched, Exceptions, Approved, Closed and Cancelled.

How it works behind the scenes

  • Reconciliation lines are append-only. Signing off twice with the same request returns the original result.
  • The evidence hash records the filters, the comparisons and the totals, so a later reviewer can confirm what was signed off.
  • Proposals posted into a later period because the original period was closed reconcile normally against their resolved posting date.

Reconciliation and period close

The Commission Period Close Checklist has a Reconciliation Zero gate. It passes only when the period has at least one reconciliation and none of them has a difference above its tolerance. A period cannot be closed until every gate has passed. See Period close and reopen.

Troubleshooting

  • A G/L entry appears as an exception with no expected account. Someone posted to the proposal's document outside the commission posting. Investigate the entry and record a resolution after correcting it.
  • BAA-ACC-RECON-FILTER. A comparison filter has invalid syntax.
  • BAA-ACC-RECON-RESOLUTION-STATE. Only an unresolved exception line of an unsigned reconciliation can be resolved.
  • Refresh is refused. The underlying evidence changed after the build. Investigate what changed. The frozen reconciliation remains the record of the original state.
// next step

Ready to try Bitta Commission?