Skip to main content

BETA - Journal entries Documentation

The BETA Journal entries model is the comprehensive accounting ledger that captures all financial transactions in our system. Think of it as the "master book" where every financial event is recorded with proper double-entry accounting principles.

Updated yesterday

Account Codes Reference

Account codes are used throughout the journal entries to categorize financial transactions. These codes follow standard accounting conventions and are categorized into four main types: Assets, Liabilities, Revenue, and Expenses.

Account Code Configuration

Custom vs. Default Codes: Account codes are customizable by Smeetz clients to match their own chart of accounts. However, the system provides default codes if clients choose not to configure custom ones.

Special Note on Sales Account Codes: For sales transactions (account code 3200), the specific code is determined by the "accounting code" field set on product prices within the Smeetz back-office. This allows organizers to have different revenue accounts for different product categories or types.

Complete Account Reference

Below is the complete list of accounts defined in the system, organized by category:

Assets (1000-1999)

Accounts representing resources owned by the organization or amounts owed to it.

Default code (customizable)

Account Name

Description

Used In

1000

Smeetz Pay acquiring

Money held by Adyen payment processor; temporary holding account before transfer to bank

Payments, Refunds, Payouts

1001

Bank Account

Organizer's bank account receiving payouts from Smeetz Pay

Payouts (bank transfers)

Multiple

Non-Smeetz Pay payment methods

Direct payment methods without Smeetz processor (offline payment methods or via external payment processor) - one account per payment method (e.g. bank transfers)

Payments, Refunds

Multiple

Cash location accounts

Cash accounts per location (Cash - Location 1, Cash - Location 2, etc.)

Cash payments, Cash transfers, Cash corrections

1050

Accounts Receivable

Money owed by customers

Sales, Discounts, Vouchers, Refunds

1110

Taxes Receivable

VAT or other taxes that are charged to the organizer

Tax on fees

Liabilities (2000-2999)

Accounts representing obligations or amounts owed by the organization.

Code

Account Name

Description

Used In

2010

Taxes Payable

Sales tax/VAT owed to tax authorities

Tax recognition

2030

Deferred Revenue

Obligation to provide services already sold

Sales, Revenue recognition, Discounts

2040

Accrued Expenses Payable

Fees and expenses owed but not yet paid

Booking fees, Payment fees, IDIV tax, Tax on fees, Payout fee deductions

2050

Vouchers Outstanding

Liability for unredeemed gift cards and vouchers

Voucher issuance

Revenue (3000-3999)

Accounts representing income earned from operations.

Code

Account Name

Description

Used In

3200

Sales

Revenue from ticket and service sales (code may be customized per product)

Revenue recognition

3060

Cash correction

Balancing account for cash overages or shortages

Cash corrections (can be used for either gains or losses)

Expenses (4000-4999)

Accounts representing costs incurred in operations.

Code

Account Name

Description

Used In

4100

Booking Fees

Platform fees for booking services

Booking fees

4200

Payment Fees

Credit card and payment processing fees

Payment fees

4300

IDIV Tax

Specific tax on fees in certain jurisdictions

IDIV tax

Understanding Account Code Categories

  • Assets (1000-1999): Things the organization owns or is owed. When debited, assets increase; when credited, assets decrease.

  • Liabilities (2000-2999): Things the organization owes. When credited, liabilities increase; when debited, liabilities decrease.

  • Revenue (3000-3999): Income earned. When credited, revenue increases; when debited (rare), revenue decreases.

  • Expenses (4000-4999): Costs incurred. When debited, expenses increase; when credited (rare), expenses decrease.

Business Logic Explained

Accounting Date Logic

Understanding when transactions are recognized for financial reporting purposes is crucial for accurate accounting. The system uses different accounting date rules depending on the transaction type and allows configurability for revenue recognition.

What is Accounting Date?

The accounting date is the date when a transaction should be recognized for financial reporting purposes. This may differ from when the transaction was recorded in the system (synchronization date) based on accounting standards and business rules.

Configurable Revenue Recognition

For revenue recognition entries (whether discount or sales), the accounting date is configurable per organizer:

  • Visit date (event/service delivery date) - for accrual accounting

    • Note: the formula here is the maximum between the visit date and synchronization date because if a sale is done for a ticket that has a visit date in the past (which is possible in Smeetz system) then it will have a revenue recognition date that matches synchronization date to avoid backdating transactions.

  • Synchronization date (when recorded in system which can be late in-case of using offline POS then syncing back to online) - for cash-basis accounting

    • Note: we specify that it’s when the transaction is recorded in our system because there is an option to use the offline POS on Smeetz meaning you can perform sales but those will only be recorded when the organizer syncs back online (e.g. you perform sales offline 2 days ago and you sync online today, this means that it will have a sync date of today), this also avoids backdating transactions.

This choice is configured in the Accounting Date Parameter configuration and applies consistently to both sale recognition and discount recognition entries.

1. Sales Transactions

Sales transactions (which are sales, discounts, or cancellations) trigger multiple accounting entries:

  • Initial Sale: Records the full amount owed by the customer (Accounts Receivable) and the obligation to provide services (Deferred Revenue).

  • Revenue Recognition: When services are delivered (according to the accounting date configuration chosen by the customer), moves money from Deferred Revenue to actual Sales Revenue.

  • Tax recognition: Properly separates and tracks sales tax amounts for tax reporting.

  • Discounts: When discounts are applied, reduces both Accounts Receivable and Deferred Revenue, discounts are generated separately because it’s possible to apply discounts at a separate time from the original sale.

  • Discount recognition: When services are delivered (according to the accounting date configuration chosen by the customer), moves discount base amount from Sales Revenue to Deferred Revenue.

  • Discount tax recognition: Properly separates and tracks discount portion of tax for tax reporting.

  • Cancellations: When sales are cancelled, reverses the original sale entries

  • Discount Cancellations: When discounts are cancelled, reverses the original discount entries.

Note: Each of these entries is created once per ticket, regardless if the tickets are from the same product or same order (e.g. even if there is a sale of 3 tickets of the same product in the same order, each of the 3 tickets will have its own entries).

Sales Entry Types

If there was a sale of a ticket with a discount applied:

Entry Type

Debit Account

Debit Amount

Credit Account

Credit Amount

Accounting Date

When Used

Sale

Accounts Receivable (1050)

Total sale price (base + VAT)

Deferred Revenue (2030)

Total sale price (base + VAT)

Synchronization date

Initial sale recorded

Sale Recognition

Deferred Revenue (2030)

Base ticket price (excluding VAT)

Sales (3200)

Base ticket price (excluding VAT)

Configurable: Visit date or Synchronization date

Revenue recognized at event date

Tax Recognition

Deferred Revenue (2030)

VAT amount

Taxes Payable (2010)

VAT amount

Synchronization date

Tax recognized

Discount

Deferred Revenue (2030)

Discount amount

Accounts Receivable (1050)

Discount amount

Synchronization date

Discount applied to sale

Discount Recognition

Sales (3200)

Discount portion of base price

Deferred Revenue (2030)

Discount portion of base price

Configurable: Visit date or Synchronization date

Discount revenue recognition

Discount Tax Recognition

Taxes Payable (2010)

Discount portion of VAT

Deferred Revenue (2030)

Discount portion of VAT

Synchronization date

Discount tax recognition

Note on Cancellations: When there is a cancellation, the debit and credit accounts are swapped to reverse the original entries. Cancellations use the cancellation synchronization date.

Net Result: Accounts Receivable = Net amount owed (after discount), Sales = Net base revenue (after discount), Taxes Payable = Net VAT (on discounted price).

2. Payment Processing

When customers pay for their purchases:

  • Payment Receipt: Records money received from payment processors and reduces what customers owe.

  • Refunds: Reverses the payment process when customers request refunds.

Payment Account Types

The system uses different types of accounts for payment processing:

Smeetz Pay Acquiring (Account Code: 1000)

  • Represents money held by the third-party payment processor (Adyen) on the organizer's behalf.

  • Acts as a temporary holding or clearing account for funds received from customers before they are transferred to the organizer's bank account

  • This is the only payment account where funds flow through Smeetz before reaching the organizer.

  • All payouts to the organizer's bank account originate from this account.

Non-Smeetz Pay Payment Methods (Custom Account Codes)

  • Represents physical currency and other direct payments received from customers without the Smeetz payment processor in between whether that’s offline payment methods or via external payment processors.

  • Each payment method configured by the organizer will have its own dedicated account and custom code.

  • These payments reach the organizer directly without Smeetz in the transaction flow.

Cash Accounts (Custom Account Codes)

  • This is only for clients that have cash locations set up.

    • Cash locations allow for cash management (cash transfers and cash corrections for overages/shortages) on separate cash locations. Locations could be linked to physical POS devices (e.g. a set of POS devices linked to the same location), or any other location the organizer want to set up (e.g Bank, Safe .. etc).

  • Each cash location has its own account (e.g., "Cash - Location 1", "Cash - Location 2").

  • Enables tracking of cash payments, transfers between locations, and location-specific cash corrections (overages/shortages).

  • Each location will have a unique custom account code set by the organizer

  • If a transaction is not linked to a set location, it will only show up with the account name “Cash” (e.g. cash payments done outside POS).

Example - Payment via Smeetz Pay: Customer pays via credit card through Smeetz Pay.

Entry Type

Debit Account

Debit Amount

Credit Account

Credit Amount

Accounting Date

Description

Payment Entry

Smeetz Pay acquiring (1000)

Payment amount

Accounts Receivable (1050)

Payment amount

Synchronization date

Payment received through Smeetz Pay processor

Payment via Cash

Customer pays cash at a location.

Entry Type

Debit Account

Debit Amount

Credit Account

Credit Amount

Accounting Date

Description

Payment Entry

Cash - Location (custom code)

Payment amount

Accounts Receivable (1050)

Payment amount

Synchronization date

Cash payment received at location

Payment via non Smeetz Pay payment method (e.g. voucher)

Customer redeems voucher at a location.

Entry Type

Debit Account

Debit Amount

Credit Account

Credit Amount

Accounting Date

Description

Payment Entry

Voucher (custom code)

Payment amount

Accounts Receivable (1050)

Payment amount

Synchronization date

Voucher payment received at location

Refund via Smeetz Pay

Customer receives refund via Smeetz Pay.

Entry Type

Debit Account

Debit Amount

Credit Account

Credit Amount

Accounting Date

Description

Refund Entry

Accounts Receivable (1050)

Refund amount

Smeetz Pay acquiring (1000)

Refund amount

Synchronization date

Refund processed through Smeetz Pay

Notes:

  • Each of these entries is created once per ticket, regardless if the tickets are from the same product or same order (i.e. even if there is a payment/refund for 3 tickets of the same product in the same order, each of the 3 will have its own entries).

3. Fees and Charges

Various operational fees are tracked:

  • Booking Fees: Platform fees charged for using our booking system, generated at the synchronization date of the sale, regardless of whether the payment is done.

  • Payment Fees: Payment processing fees, will be charged at a different time depending on whether the client has an IC++ set up or not.

    • Clients without IC++: payment processing fees are generated when the payment is recorded (payment synchronization date).

    • Clients with IC++ set up: payment processing fees are generated when the payment is settled, i.e. when the payment is reconciled with the payment processor (which can be later from when the payment is recorded).

  • IDIV Tax: Specific tax on fees applicable for Lausanne clients. Taken as a percentage from net sales (regardless whether it’s paid or not), and it’s generated when the booking statement is created.

  • Tax on Fees: VAT applied to the booking and payment fees.

Booking Fee

Booking fee charged at sale.

Entry Type

Debit Account

Debit Amount

Credit Account

Credit Amount

Accounting Date

Description

Booking Fee Entry

Booking Fees (4100)

Booking fee amount

Accrued Expenses Payable (2040)

Booking fee amount

Sale synchronization date

Platform fee charged at sale

Payment Fee

Entry Type

Debit Account

Debit Amount

Credit Account

Credit Amount

Accounting Date

Description

Payment Fee Entry

Payment Fees (4200)

Payment fee amount

Accrued Expenses Payable (2040)

Payment fee amount

depending on IC++ setup (details above)

Payment processing fee

IDIV Tax

Entry Type

Debit Account

Debit Amount

Credit Account

Credit Amount

Accounting Date

Description

IDIV Tax Entry

IDIV Tax (4300)

IDIV tax amount

Accrued Expenses Payable (2040)

IDIV tax amount

When the booking statement is created

IDIV tax on net sales

Tax on Fees

Entry Type

Debit Account

Debit Amount

Credit Account

Credit Amount

Accounting Date

Description

Tax on Fees Entry

Taxes Receivable (1110)

Tax amount on fees

Accrued Expenses Payable (2040)

Tax amount on fees

When the booking statement is created

VAT charged on fees

4. Voucher Management

Lifecycle tracking for gift cards and vouchers:

  • Voucher Issuance: When gift cards or vouchers are sold (regardless of whether they’re paid for or not), records the liability to provide future services.

Voucher Issuance

Customer buys gift card (only the sale not the payment):

Entry Type

Debit Account

Debit Amount

Credit Account

Credit Amount

Accounting Date

Description

Voucher Issuance Entry

Accounts Receivable (1050)

Voucher value

Vouchers Outstanding (2050)

Voucher value

Synchronization date

Gift card sold to customer

Note: When a voucher is redeemed, it's treated as a payment method, so the redemption follows the standard payment transaction flow.

5. Cash Management

Financial adjustments and transfers:

  • Cash Transfers: Moving money between different cash accounts (which are explained in “Cash accounts” section).

  • Cash Corrections (Gain): Adjustments for accounting overages (when physical cash is more than expected).

  • Cash Corrections (Loss): Adjustments for accounting shortages (when physical cash is less than expected).

Cash Transfer

Transfer between cash locations.

Entry Type

Debit Account

Debit Amount

Credit Account

Credit Amount

Accounting Date

Description

Cash Transfer Entry

Cash - Destination Location (custom code)

Transfer amount

Cash - Source Location (custom code)

Transfer amount

Synchronization date

Cash transferred between locations

Cash Correction (Gain)

Found extra cash in drawer at a location.

Entry Type

Debit Account

Debit Amount

Credit Account

Credit Amount

Accounting Date

Description

Cash Correction Gain Entry

Cash - Location (custom code)

Overage amount

Cash Correction (3060)

Overage amount

Synchronization date

Cash overage adjustment

Cash Correction (Loss)

Cash shortage in drawer at a location.

Entry Type

Debit Account

Debit Amount

Credit Account

Credit Amount

Accounting Date

Description

Cash Correction Loss Entry

Cash Correction (3060)

Shortage amount

Cash - Location (custom code)

Shortage amount

Synchronization date

Cash shortage adjustment

6. Payout Operations

Records the movement of funds from Smeetz Pay acquiring account (minus the fees) to organizer's bank account:

  • Fee Deductions: Deduction of accumulated fees from the payout.

  • Bank Transfers: Bank transfers from Smeetz Pay acquiring (minus the fees) to organizer bank accounts.

Fee Deduction from Payout

Accumulated fees deducted from payout.

Entry Type

Debit Account

Debit Amount

Credit Account

Credit Amount

Accounting Date

Description

Fee Deduction Entry

Accrued Expenses Payable (2040)

Total fees amount

Smeetz Pay acquiring (1000)

Total fees amount

When the booking statement is created

Fees deducted from payout

Bank Payout

Funds transferred to organizer's bank account.

Entry Type

Debit Account

Debit Amount

Credit Account

Credit Amount

Accounting Date

Description

Bank Transfer Entry

Bank Account (1001)

Payout amount

Smeetz Pay acquiring (1000)

Payout amount

Value date of the bank transfer

Funds transferred to bank

Data Structure

Column Definitions

Each record in Journal Entries Final contains the following columns:

Timing Columns

  • Synchronization Date (DATETIME): The date and time when the business event was completed and synchronized to our database. This represents when the transaction was recorded in our system.

  • Creation Date (DATETIME): The timestamp when the original transaction record was first created in the source system.

  • Modification Date (DATETIME): The timestamp when the transaction record was last modified or updated.

  • Accounting Date (DATETIME): The date when the transaction should be recognized for financial reporting purposes. This may differ from the synchronization date based on accounting rules (explained in "Accounting Date Logic" section above).

Transaction Identification

  • Journal Entry ID (STRING): A unique identifier for each journal entry, composed of the transaction ID and entry type identifier (e.g., "12345S", "12345F"..). This ensures each accounting entry can be uniquely identified and traced back to its source.

  • Event (STRING): The high-level business event category (e.g., "Sales", "Payment", "Fees", "Voucher", "Cash transfer", "Payout"). This provides a simplified grouping for reporting.

Account Information

  • Debit Account Code (STRING): The numeric code identifying the account to be debited (e.g., "1050", "2030", "3200").

  • Debit Account Name (STRING): The descriptive name of the account to be debited (e.g., "Accounts Receivable", "Deferred Revenue", "Sales").

  • Credit Account Code (STRING): The code identifying the account to be credited.

  • Credit Account Name (STRING): The descriptive name of the account to be credited.

Monetary Values

  • Debit Value (NUMERIC): The amount to be recorded as a debit. Always a positive number representing the increase in the debit account.

  • Credit Value (NUMERIC): The amount to be recorded as a credit. Always a positive number representing the increase in the credit account. Should always equal Debit Value for balanced entries.

Reference Information

  • Order Reference (STRING): The customer-facing order reference for traceability by orders. Shows as "N/A" for fee and payout transactions that don't have associated orders.

  • Booking Statement ID (STRING): The internal booking statement identifier used for linking transactions to specific booking statements.


This model follows standard accounting principles and provides a complete, auditable record of all financial transactions in the system.

Did this answer your question?