The Accounting Settings page gives you control over how your financial data is structured and recorded. Navigate to Account details -> Accounting settings, you'll find two tabs: Account Codes and Modeling.
⚠️ Important: Any changes made here affect your accounting reports retroactively (i.e., they impact historical data). Changes take effect within 4 hours due to the accounting report refresh rate.
Tab 1: Account Codes
This tab consolidates all your accounting accounts in one place for easy management.
You can customize the account codes used in your accounting reports. Each account has:
Accounting Code – A unique numeric identifier (e.g., 1000, 1010, 1020)
Account Name – A descriptive label for the account (e.g., Cash, Marketplaces)
Description – Additional context about what the account represents
Default accounts are listed in this documentation: https://knowledge.smeetz.com/en/articles/12783353-beta-journal-entries-documentation#h_5b6a5aa686
💡 Sales account codes can also be set directly from the price configuration page: Products → Tickets → Prices → Accounting Code
Tab 2: Modeling
This tab controls two key accounting behaviors:
Revenue Recognition Date
This setting determines when revenue is recognized in your accounting entries.
Option 1: Based on synchronization date (default – suitable for cash-basis accounting)
Revenue is recognized on the date the transaction is recorded in the Smeetz system.
📝 Note on offline POS: If you use Smeetz's offline Point of Sale, sales are only recorded when you sync back online. For example, if you made sales 2 days ago and sync today, the synchronization date will be today's date. This prevents backdating of transactions.
Option 2: Based on validity date (suitable for accrual accounting)
Revenue is recognized on the event/service delivery date (i.e., the visit date).
📝 Note: The system uses the maximum of the visit date and the synchronization date. This handles edge cases where a ticket is sold after the event has already taken place — in that scenario, the synchronization date is used to avoid backdating transactions.
How this affects accounting entries:
Entry Type | Accounting Date |
Revenue / sales entries | Based on your chosen setting (synchronization date or validity/visit date) |
Payment entries | Always the actual payment date, regardless of the setting above |
This means: if you filter your accounting report by a specific date and you're using the validity date setting, you will see both the sales entries and payment entries that fall on that date, each using their respective accounting dates.
When Option 2 (validity date) is selected, revenue is normally recognized on the visit date. However, retail items don't have a visit date, so additional rules apply when retail is sold alongside or added to a ticket.
Ticket only: Recognized on the visit date, per the standard rule (max of visit date and sync date).
Retail only: No visit date exists, so revenue is recognized on the synchronization date.
Ticket and retail in the same transaction purchased together: Both items follow the ticket's visit date.
Retail added to an existing order after the initial purchase: The accounting date for the retail item depends on the state of the order's tickets when the retail is added:
If one or more tickets still have a future visit date, the retail is recognized on the earliest future visit date.
If all tickets in the order have visit dates in the past, the retail is recognized on the synchronization date.
Quick reference
Scenario | Accounting date for retail |
Ticket only (no retail) | Visit date (standard rule) |
Retail only | Sync date |
Ticket + retail purchased together | Ticket's visit date |
Retail added later, future tickets exist in the order | Earliest future visit date |
Retail added later, all tickets are in the past | Sync date |
📝 Note: This logic ensures retail revenue is tied to the customer's visit whenever a meaningful future visit date exists, and falls back to the sync date in all other cases to avoid backdating.
Discount Modeling
This setting determines how discounts are recorded in your accounting entries.
Option 1: Same account as sales account (default)
Discounts are deducted directly within the same sales account. No separate line is created for discounts.
Option 2: Separate account
Discounts are recorded in a dedicated discount account:
Account Name: Discount
Account Code: 2030
This gives you clearer visibility into discount amounts separately from your revenue figures.
Saving Changes
Click Save changes to apply your settings, or Reset to revert to the previously saved configuration.