Audit Trail And Controls

Pinkapple keeps a permanent record of important accounting activity so finance teams can explain who did what, when it happened, and why it affected the books.

Use this guide when reviewing audit evidence, preparing for external audit, investigating an accounting change, or confirming that period and journal controls are working as expected.

Workspace Reference

Workspace	How Users Reach It	What Users Usually Do There
GL Journals	Accounting -> Operations -> GL Journals	Review journal status, source references, approval history, reversals, and posting outcomes.
GL Posting Approval	Accounting -> Setup -> GL Posting Approval	Review maker-checker controls, approval chains, policies, and pending GL approvals.
Fiscal Periods	Administration -> Financial Setup -> Fiscal Periods	Review period close, reopen, lock, and posting-control history.
GL Reconciliation	Accounting -> Operations -> GL Reconciliation	Confirm control-account and sub-ledger evidence before close or audit review.
Service Workspaces	Operational modules that generated the accounting record	Open the original business record behind a journal or audit event.

What The Audit Trail Shows

The audit trail records user and system actions across financial workspaces. Depending on the action, users can review:

Information	What It Helps You Confirm
Action taken	Whether the record was created, changed, approved, posted, reversed, or voided.
Affected record	Which journal, fiscal period, budget, posting rule, or related accounting record changed.
Before and after	What changed during an edit or approval action.
User and time	Who performed the action and when it happened.
Business unit	Which branch, unit, or service context the action belonged to.
Status	Whether the action completed, remained pending, was rejected, or was reversed.
Notes or reasons	The business reason captured by the user where the action requires one.

The audit trail is not optional user commentary. It is captured automatically as users perform controlled actions.

Posted Entries Are Protected

Once a journal entry is posted, it becomes part of the accounting record. Users should treat it as final ledger history.

Posted entries are protected in these ways:

• Amounts and accounts cannot be silently changed after posting.
• Posted entries are not deleted from ledger history.
• Corrections are made through controlled reversals or new adjustment entries.
• The original entry remains visible for review.
• The correction keeps a traceable relationship to the original action.

This protects auditability. Finance users should avoid asking administrators to “edit the posted entry” and instead use the correct reversal or adjustment workflow.

Voids And Reversals

Voids and reversals solve different problems.

Action	When To Use It	Accounting Meaning
Void	A draft or unposted item was created in error and should not proceed.	The item remains visible but should not affect balances.
Reverse	A posted item must be corrected after it already affected the ledger.	A new opposite entry offsets the original entry.
Adjustment	A valid posted item needs an additional correction or reclassification.	A new entry records the correction without hiding history.

Use action notes clearly. A reversal or period reopen without a useful reason creates audit questions later.

Period Controls

Fiscal periods move through controlled states so users cannot continue posting into periods that finance has closed.

Period State	User Meaning
Open	Normal posting is allowed.
Soft Closed	Routine posting is restricted; only governed adjustments are allowed.
Hard Closed	The period is final and cannot receive ordinary postings.
Locked	The period is retained as final historical record.

Before closing a period, finance should confirm:

• journals and batches are posted or intentionally held
• approvals are complete
• sub-ledger and control-account balances reconcile
• till or cash sessions are closed where required
• backdated or future-dated items are understood

Segregation Of Duties

Pinkapple supports maker-checker control. The same user should not create and approve the same governed financial action where approval rules require independent review.

Common examples include:

• one user creates a journal and another approves it
• one user prepares a payment batch and another approves it
• one user submits a budget change and another approves it
• one user closes a period and another reviews close readiness

Administrators configure roles and approvals so the system reflects the organisation’s control policy.

Control Account Reconciliation

Some accounts are control accounts. They summarise balances that are also tracked at a more detailed level, such as by customer, supplier, loan account, deposit account, till, wallet, or bank account.

For these accounts, users should expect the system to require the detailed tracking side to remain aligned with the control-account balance.

If a reconciliation check fails:

• identify the account and business unit affected
• check whether a related sub-ledger or party mapping is missing
• review recent posted entries against the control account
• correct the underlying mapping or transaction rather than forcing the close

Balanced Entry Controls

Accounting entries must balance. Total debits must equal total credits before posting can complete.

If posting is blocked because an entry is not balanced, the likely causes are:

• missing rule detail on one side of the entry
• a tax, fee, charge, or rounding line was not configured
• a dynamic account mapping could not be resolved
• a line was cancelled or failed but the source workflow still included it in posting

Users should correct the setup or source workflow, then retry the controlled action.

Cash And Funding Controls

Cash, till, bank, wallet, and mobile money funding accounts may have additional controls. These controls prevent users from treating unavailable funds as spendable.

Before approving or posting a funding movement, check:

• the selected channel and currency
• the business unit or service wallet
• the till, drawer, or bank account where applicable
• available balance before the transaction
• any holds, pending transactions, or reconciliation exceptions

What Auditors Usually Ask For

During audit or investigation, users commonly need to provide:

• the original business record
• the related journal or posting outcome
• the approval history
• the user who created, approved, posted, reversed, or voided the item
• the reason notes entered during reversal, rejection, reopening, or adjustment
• evidence that the period was open or appropriately reopened
• evidence that control-account balances reconciled at close

Common Mistakes

Mistake	Better Practice
Editing master data to hide a posting issue.	Correct the posting through reversal or adjustment.
Reopening a period without a reason.	Enter a clear business reason and reference supporting work.
Ignoring a control-account mismatch.	Resolve the detailed balance issue before closing.
Treating a posted error as deletable.	Use reversal or adjustment so history stays complete.
Giving one user all create and approve duties.	Separate duties using roles and approval configuration.

Related Pages

• Journal Entry Controls
• GL Posting Approval
• Month-End Close
• GL Reconciliation