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.
