Posting Dates and Periods

This guide explains how PinkApple decides whether a GL posting date is allowed, which fiscal period it belongs to, and when a posting is treated as a normal post, a late post, or an adjustment.

Core Dates

PinkApple uses several different date concepts in the posting workflow:

• Journal Date: the accounting effective date of the journal entry
• Transaction Date: the line-level effective date; when omitted, it follows the journal date
• Business Day: the operational day used mainly by teller and till-based posting
• Fiscal Period: the accounting period that contains the journal date

These dates are related, but they are not the same thing.

Channel Rules

Teller Posting

Teller posting is operational and business-day driven.

• The journal date follows the active business day
• An active till session is required
• Posting remains tied to the teller business day and till session
• Backdated and future-dated teller posting is not the normal workflow

Back-Office Posting

Back-office posting is accounting-date driven.

• The selected journal date is preserved as the actual accounting date
• The posting engine validates whether that date is still postable
• The entry affects balances on that selected date
• Future-dated and backdated posting rules apply here

Open Periods

Every business unit has a fiscal period state for each period.

Common statuses include:

• OPEN: normal posting is allowed
• SOFT_CLOSED: posting may still be allowed if soft-closed posting is enabled
• CLOSING / HARD_CLOSED / LOCKED: normal posting is blocked
• NOT_OPENED: the period is not yet available for posting

The calendar policy controls how many normal periods may remain open at the same time through max open periods.

If multiple normal periods are open, back-office users may post to any of those open periods, subject to the backdated or future-dated configuration.

Backdated Posting

GL_ALLOW_BACKDATED_POSTING controls whether users may post with a journal date earlier than today.

When backdated posting is enabled:

• users may post to a past date inside an open normal period
• users may also qualify for late posting into the immediately preceding closed normal period if the lag window is still open

When backdated posting is disabled:

• past-dated posting is blocked, even if the period is open

Posting Lag Days

Calendar policy includes default posting lag days.

Lag days do not extend the real accounting period dates. Instead, they define a short grace window for posting into the immediately previous closed normal period after a later normal period has already opened.

Example:

• March closes on March 31
• April opens
• Posting lag days = 5

Then:

• from April 1 through April 5, back-office users may still create March journals
• the stored journal date remains the actual selected March date
• after April 5, March is no longer postable through the lag window

Future Posting

GL_ALLOW_FUTURE_POSTING controls whether users may post with a journal date later than today.

When future posting is enabled:

• the selected future journal date is preserved
• the batch is stored as a scheduled future post until its journal date arrives
• mutating handlers such as CREATE and UPDATE are deferred until scheduled execution time
• the actual journal posting, balance impact, and deferred handler side effects happen on the due date

Future posting should still be limited to periods that are actually open for posting.

Important:

• this is different from immediate posting with a future date
• if reporting needs to show projected future balances before the due date, that should be handled as a reporting/projection feature, not by mutating actual balances early

Adjustment Periods

Adjustment periods are special periods configured by the calendar policy through adjustment period count.

When an adjustment period is open:

• historical correction posting can be allowed even after the normal lag window has expired
• the actual selected journal date is preserved
• the posting is treated as an adjustment-mode posting in workflow and approval logic

Adjustment periods are intended for controlled post-close corrections, not routine operational posting.

How PinkApple Classifies a Posting

For back-office posting, the system resolves one of these modes:

• REGULAR: the selected date is inside a currently postable normal period
• LATE_POST: the selected date is in the immediately previous closed normal period, but still within lag days
• ADJUSTMENT: the selected date is historical and is being allowed because an adjustment period is open

This resolution is returned by the posting context and should be treated as the source of truth for the UI and approval rules.

Approval and Adjustment Posting

Adjustment posting should normally be controlled through GL Posting Approval Policies, not by a standalone switch alone.

Recommended policy examples:

• posting_mode = ADJUSTMENT
• is_adjustment = 1
• is_backdated = 1 for late or historical correction flows

This keeps adjustment approval inside the same approval chain and authority model used for all other GL posting approval.

Practical Guidance

Use this decision order:

1. Is the selected date inside an open normal period?
2. If not, is it inside the immediately previous closed normal period and still within lag days?
3. If not, is an adjustment period open and should this be treated as an adjustment?
4. If none of the above is true, the date is not postable.

Related Pages

• Back-Office Posting
• Teller Posting
• GL Posting Approval
• Fiscal Periods
• Calendar Policy