Solution design and validation

note

This document apply to solution versions 6.0.0 onwards. For prior versions, please refer to the Zap Help Center.

This reference document provides comprehensive information about the design principles and configuration options for pre-built Zap Data Hub solutions. These solutions are pre-packaged data models designed specifically for your CRM or ERP systems, and include a collection of ready-to-use analytics such as tables, charts, and dashboards for both Zap Analytics and Power BI.

Use this document as your primary reference during initial implementation and revisit it whenever your ERP configuration changes or your reporting requirements evolve. Understanding these design principles will help you effectively manage your data models and create custom analytics that align with your business needs.

Common design details

The following design principles and configuration options apply universally across all modules within Zap Data Hub solutions.

Processing and refresh schedules

Zap Data Hub solutions include pre-configured schedules that automatically refresh your data to keep it current with your source systems. By default, these schedules run nightly to ensure you have up-to-date information available each morning.

If your license plan permits, you can increase the refresh frequency to support higher throughput reporting. However, be aware that scheduling more frequent automatic refreshes may prevent you from triggering on-demand refreshes when needed. Consider your business requirements carefully when adjusting refresh frequencies; most organizations find that nightly refreshes provide an appropriate balance between data currency and system performance.

Handling deleted records

The default processing configuration is designed to capture records that have been deleted from your source system, ensuring you maintain a complete historical record. The system employs a nightly process that checks for deleted records within a configurable 60-day rolling window. This window-based approach balances the need for data integrity with processing efficiency.

For organizations requiring more comprehensive delete detection, you have two additional options available:

1. You can enable a monthly full-load process that catches deletions occurring outside the standard 60-day window. This is particularly useful for capturing administrative activities such as record archiving that may happen infrequently.

2. If your source system supports direct change-tracking mechanisms (available in SQL Server and certain other platforms), you can enable higher-frequency synchronization that detects and processes deletions in near real-time.

Source data filtering

To ensure reporting accuracy and relevance, source tables are automatically filtered to include only posted records where applicable. This filtering prevents draft or pending transactions from affecting your analytics. You can review and adjust these filters by accessing the configuration settings on the respective pipelines.

By default, all historical records are included in your data model, giving you a complete view of your business history. If you need to limit the historical data scope, you have two options: configure date filters on individual pipelines for module-specific control, or use the Global date filter setting to apply a consistent date range across all modules.

Currency translation

Zap Data Hub handles multi-currency environments by translating all amounts into a single reporting currency. The reporting currency defaults to the primary company currency configured during your initial setup. If you need to change the reporting currency after deployment, you can update this setting in the model parameters.

Unless specifically qualified with the label "(functional)", all currency measures displayed in reports and analytics are presented in the reporting currency. This standardization allows you to compare and aggregate financial data across entities that operate in different currencies.

The system sources exchange rates directly from your ERP system, ensuring consistency with your source data. However, it's important to understand that different modules apply exchange rates differently based on accounting best practices:

Historical rate translation is used for Sales, Purchasing, Production, and Inventory modules. These operational modules translate transactions using the exchange rate that was in effect on the transaction date, preserving the historical economic reality of each transaction.

As-of date translation is used in accounts receivable, accounts payable, and general ledger reports. These financial modules translate currency amounts at the report level using the exchange rate in effect as of the report date. This approach ensures that balance sheet items reflect current valuations, which is critical for accurate financial reporting.

Fiscal periods and financial calendars

Your fiscal period structure synchronizes automatically with your ERP system, ensuring that period-based reports align with your organization's financial calendar. This synchronization happens as part of the regular data refresh process, so changes to fiscal periods in your ERP are reflected in Zap Data Hub without manual intervention.

Financial calendars, which define how your organization structures its reporting periods, are configured during the initial setup process. Unlike fiscal periods, financial calendars can be edited at any time through the model parameters if your reporting structure changes. This flexibility allows you to adapt your reporting framework as your business evolves.

Time zone considerations

The reporting time zone is a critical configuration setting that is established during initial setup. This setting affects how timestamp data is interpreted and displayed throughout the solution. It's particularly important for two key scenarios:

1. For data fields that include time components, such as order completion times, shipment timestamps, or transaction timestamps, the time zone conversion determines which date these events are assigned to in reports. For example, a transaction timestamped at 11:00 PM in one time zone might fall on a different date when converted to your reporting time zone. Establishing a consistent reporting time zone ensures that all transactions are assigned to dates uniformly, regardless of where they originated.

2. The reporting time zone determines the date assignment for historical snapshots used in aging analysis. When the History Step process captures point-in-time snapshots for aging reports, it uses the configured time zone to determine which date the snapshot belongs to. This is essential for accurate day-based aging calculations, as the same moment in time could represent different dates depending on the time zone used.

Inline documentation and AI assistance

Every data model and analytics component within Zap Data Hub includes inline documentation with solution-specific details. This documentation is embedded directly in the interface, providing contextual help exactly where you need it.

Rather than reading through extensive documentation, you can use Zap AI to answer questions about the data model, calculations, or specific analytics. Zap AI can explain how measures are calculated, what dimensions are available, and how different components of the solution work together. This makes it easy to understand and work with the solution without needing to consult external documentation for routine questions.

Validation

Validation is a critical step that confirms your Zap data model accurately aligns with your source ERP system. This process ensures that key configurations match your business requirements and ERP setup.

For example, validation helps you confirm whether on-hand inventory represents physical stock only, or whether it includes inbound stock that hasn't yet been received. These definitional differences can significantly impact reporting and decision-making, so it's important to verify them during implementation.

Validation approach for operational modules

For non-financial modules such as Sales, Purchasing, Inventory, and Production, you should validate your data using summary reports. Each module includes summary reports specifically designed for validation purposes. Compare these summary reports to equivalent reports generated directly from your ERP system to identify any discrepancies.

These validation reports are built on snapshot data that reflects the state of your data at the time of the last refresh. To avoid false discrepancies caused by transactions posted after your Zap refresh but before your ERP report was generated, always validate against data from a prior completed period rather than the current period. This timing consideration is crucial for accurate validation.

Checking refresh timing

You can hover over report tabs to see the timestamp of the last data refresh. If you need more current data and your user role permits, you can trigger an on-demand refresh by following the instructions in the link provided in the interface.

Diagnosing discrepancies

When you identify differences between Zap reports and ERP reports, you can drill down to investigate the root cause. Double-click on any value in a report to drill through and view the underlying transactions that contribute to that value. Use the slicers (filters) available in the detail views to narrow down and reconcile specific transactions with your source data. In most cases, discrepancies are the result of refresh timing issues rather than calculation errors.

Validation approach for financial modules

Financial validation follows a different process than operational module validation. See the General ledger section below for specific guidance on validating financial reports, including Trial Balance, Profit and Loss, and Balance Sheet reports.

When to perform validation

Validation is typically performed during initial implementation to establish that the solution is configured correctly. You should revisit the validation process whenever you make changes to your ERP configuration or when your reporting requirements change. Examples of changes that warrant revalidation include modifications to your chart of accounts, changes to fiscal period definitions, adjustments to costing methods, or implementation of new currencies.

Review the relevant module-specific sections below before beginning your validation process to understand module-specific considerations.

General ledger

Financial report types

Zap Data Hub provides several financial report templates that serve different purposes based on your reporting needs and accounting cycle timing.

Trial balance reports

The trial balance report is available in two variations that handle closing transactions differently:

• Trial balance (post-close) - includes all closing transactions in the report. Use this version when you need to see the final state of accounts after period-end closing entries have been posted. This is the appropriate report for verifying that all closing processes have been completed correctly and for preparing final financial statements.

• Trial balance (pre-close) - excludes closing transactions from the report. This version is useful during the closing process when you want to review account balances before posting closing entries, or when you need to analyze operational results without the impact of closing adjustments.

Profit and loss reports

Report templates

Two standard profit and loss templates are included in the solution:

• Profit and loss - provides a standard income statement for a single legal entity. Use this report when analyzing the performance of individual companies or business units.

• Profit and loss (consolidated) - combines financial results across multiple legal entities. This report is essential for organizations with multiple subsidiaries or operating companies. See the Consolidation section below for important considerations regarding consolidated reporting.

Sign flipping for proper presentation

Profit and loss amount measures automatically use the sign settings configured on each account in your chart of accounts to ensure amounts display with the correct sign convention for income statement presentation. This means revenue accounts display as positive amounts and expense accounts display as positive amounts, even though they may have different debit/credit conventions in the underlying general ledger.

In some circumstances, you may need to manually invert the sign for specific accounts. Contra accounts are a common example: a contra revenue account should display as a reduction to revenue (negative) rather than as a positive amount. To handle these situations, use the sign flipping feature of analysis reports.

Balance sheet reports

Report templates

• Balance sheet - provides a standard statement of financial position for a single legal entity.

• Balance sheet (consolidated) - combines balance sheet data across multiple legal entities, applying appropriate currency translation at the report level. See the Consolidation section for additional details on consolidation methodology.

Retained earnings configuration

The balance sheet templates include dedicated rows for current-year earnings and brought forward earnings, which together comprise your total retained earnings. The treatment of these earnings components is controlled by two key calculations that you can customize to match your organization's accounting practices.

To configure how earnings are calculated and presented, you need to edit the Balance sheet opening and Balance sheet closing calculations. You can access these calculations from the design pane by double-clicking on the calculation name. The interface includes in-app tooltips that provide step-by-step configuration guidance when you're editing these calculations.

Consolidation considerations for balance sheets

When generating consolidated balance sheet reports, the solution translates asset and liability amounts at the report level using the exchange rate as of the report date. This as-of-date translation ensures that all balance sheet items reflect current valuations in the reporting currency.

To maintain the fundamental accounting equation (Assets = Equity + Liabilities), the consolidated balance sheet automatically includes a currency exchange adjustment row. This adjustment row captures translation gains and losses that result from converting balance sheet items from functional currencies to the reporting currency. Without this adjustment, the balance sheet would not balance when currencies have moved since the original transaction dates.

Consolidation

Zap Data Hub automatically consolidates data from multiple companies into a single unified data warehouse, even when those companies are spread across separate databases in your ERP system. This consolidation process includes automatic currency translation using exchange rates sourced directly from your ERP.

The solution applies different translation methods based on the type of financial data: balance sheet rates (as-of-date rates) are used for assets and liabilities, while historical rates (transaction-date rates) are applied where appropriate for income and expense items. This dual-rate approach follows standard consolidation accounting principles.

While Zap Data Hub includes consolidated financial report templates that are suitable for many reporting scenarios, achieving full financial consolidation that complies with accounting standards typically requires additional configuration. A complete consolidation framework includes a defined consolidated chart of accounts that maps individual company accounts to consolidated reporting categories, as well as custom business rules specific to your organizational structure.

Intercompany eliminations and consolidation hierarchies

Intercompany eliminations, such as removing intercompany receivables and payables, or eliminating intercompany sales and purchases, are unique to each organization's specific legal entity structure and business relationships. Similarly, consolidation hierarchies that define ownership percentages and consolidation methods (full consolidation, proportionate consolidation, or equity method) must be customized for your organizational structure.

These advanced consolidation requirements are implemented through a professional services engagement. If you need to implement intercompany eliminations or define custom consolidation hierarchies, please contact your account manager or Zap support team to discuss your specific requirements and scope a services engagement.

Accounts payable and receivable

Aging method configuration

The aging method determines how the system calculates the age of outstanding invoices and organizes them into aging buckets. This is a critical configuration setting that affects how you view and manage your receivables and payables. You can select your preferred aging method through the model parameters.

Five aging methods are available:

• By invoice date (default) - Calculates age as the number of days from the invoice date to today's date. This is the most commonly used method and provides a straightforward view of how long invoices have been outstanding since they were issued. Use this method when you want to track the absolute age of invoices regardless of payment terms.

• By due date - Calculates age as the number of days from the invoice due date to today's date. This method is useful when you want to focus on overdue amounts and prioritize collection efforts based on how past-due invoices are. Invoices that haven't reached their due date will show as negative days (not yet due).

• By fiscal month - Calculates age based on the fiscal period gap between the invoice posting period and the current AR control period. This method organizes aging by accounting periods rather than calendar days, which can be useful for organizations that manage their receivables on a period-by-period basis aligned with monthly close processes.

• By aged statement - Uses the last four period-end dates to define aging buckets. The "Current" bucket combines the most recent two periods, and then creates 30-day, 60-day, and 90+ day buckets based on the invoice date compared to historical period end dates. This method provides a period-based view that aligns with traditional aged receivable statements.

• By statement - Also uses the last four period-end dates, but with a different definition of "Current". In this method, "Current" includes only invoices dated after the most recent period end, and then creates 30-day, 60-day, 90-day, and 90+ day buckets by comparing the invoice date to period end dates. This provides a more conservative view of current receivables.

Aging bucket configuration

The Aging bucket dimension comes pre-configured with standard 7-day, 15-day, and 30-day aging buckets that work well for most organizations. These buckets allow you to segment your receivables and payables into meaningful categories for analysis and reporting.

tip

Aging buckets can be added and configured by editing the Aging buckets pipeline.

Historical snapshots for point-in-time reporting

Aging reports in Zap Data Hub use point-in-time snapshots rather than recalculating aging based on current data. Each snapshot captures the exact balances and aging status as of the snapshot date, creating a historical record that doesn't change even if subsequent adjustments are made to the underlying data.

This snapshot approach has an important implication: if you back-post transactions to prior periods in your ERP system (for example, posting an invoice dated last month but entered this month), these back-posted transactions will not update historical snapshots that were taken before the back-posting occurred. This design is intentional: it preserves the historical record and ensures that your aging reports reflect what you actually knew at each point in time.

note

Reporting on historical data is only available on Gold and Platinum license plans.

On the Silver plan, you can only report on the latest values. However, your historical changes are still captured, and will become available if you upgrade your plan.

Operations modules

Sales module

Key date field

The Sales module uses Invoice date as the primary date field for reporting and time-series analysis. All date-based slicers, filters, and time intelligence calculations reference the invoice date unless specifically noted otherwise.

Key calculations

• Gross margin - Calculated as Net sales invoice line amount minus Cost of sales. This measure shows the profit earned on sales before considering operating expenses. Gross margin is fundamental to understanding your pricing effectiveness and product profitability.

• Net sales invoice line amount - Represents the actual revenue recognized from each invoice line. It is calculated as the Line total (Quantity multiplied by Price) minus any discounts, plus any surcharges. This net amount reflects what you actually received after all line-level adjustments, providing a true picture of revenue by product, customer, or other dimensions.

Purchasing module

Key date field

The Purchasing module uses Invoice date as the primary date field for reporting. This ensures consistency with the Sales module and aligns with when costs are recognized in your financial statements.

Key calculations

• Net purchase invoice line amount - Represents the actual cost incurred for each purchase. It is calculated as the Line total (Quantity multiplied by Price) minus any discounts, plus any surcharges. This calculation mirrors the sales calculation, but from the purchasing perspective.

• Purchase price variance amount - Captures the difference between what you actually paid for items and their standard cost. It is calculated as (Actual purchase price minus Standard price) multiplied by Invoiced quantity. This variance measure is critical for organizations using standard costing, as it highlights procurement performance and cost control effectiveness. Positive variances indicate you paid more than the standard cost, while negative variances indicate favorable purchasing below standard cost.

Inventory module

Costing method

The inventory costing method (such as FIFO, LIFO, Average Cost, or Standard Cost) is determined by your source ERP system configuration. Zap Data Hub respects and applies the costing method defined in your ERP, ensuring that inventory valuations in reports match your financial system. You cannot change the costing method in Zap Data Hub; this must be managed in your source system.

Key date field

The Inventory module uses Posting date as the primary date field. This represents when inventory transactions were actually posted to the system and became part of the official inventory record.

Key calculations

• Available - Represents the quantity available for sale or use. It is calculated as on-hand minus committed plus on-order. This measure gives you a realistic view of what inventory you can actually promise to customers or use in production, accounting for stock that's already allocated to orders and stock that's expected to arrive.

• Committed - Represents inventory that is reserved or allocated to open documents such as sales orders or production orders. This quantity is physically on-hand but not available for new orders.

• Days in Inventory - Measures how long inventory sits before being sold. It is calculated as Days in period divided by Inventory turnover ratio. This metric helps you understand inventory efficiency—lower days in inventory generally indicates faster-moving stock and more efficient working capital usage.

• Inventory to sales ratio - Compares your inventory investment to your sales volume. It is calculated as Average inventory valuation divided by Net sales invoice line amount. This ratio helps you understand whether your inventory levels are appropriate for your sales volume.

• Inventory turnover ratio - Measures how many times your inventory "turns over" in a period. It is calculated as Cost of sales amount divided by Average inventory valuation. Higher turnover generally indicates efficient inventory management, though optimal turnover rates vary by industry and business model.

• On-hand - Represents the physical inventory quantity currently in your warehouse. It is calculated as posted receipts minus posted issues. This is your actual physical stock, regardless of commitments or pending orders.

• On-order - Represents inventory that has been ordered but not yet received. It is calculated as open purchase orders plus production receipts expected. This measure helps you anticipate future inventory availability.

Production module

Key date field

The Production module uses Production order date as the primary date field. This represents when production orders were created or scheduled, which is the most relevant date for production planning and analysis purposes.

Key calculations

• Actual cost amount - Represents the total actual costs incurred to complete production. It is calculated as Actual component cost plus Actual resource cost. Component costs include the cost of raw materials and sub-assemblies consumed, while resource costs include labor and machine time. This measure reflects what you actually spent on production.

• Planned cost amount - Represents the expected costs based on the production order specifications. It is calculated as Expected component cost plus Expected resource cost. Comparing planned costs to actual costs helps you identify production inefficiencies and cost overruns.

Additional resources

For questions about specific calculations, data model structure, or how to use particular features, you can ask Zap AI directly within the Zap Data Hub interface. Zap AI has comprehensive knowledge of the solution design and can provide immediate answers without requiring you to search through documentation.

For issues related to data connectivity, user access, or other technical support needs, please contact Zap support through your standard support channels.