Period-Chunked Extraction
How VersionForge breaks large GL extractions into fiscal period chunks to avoid NetSuite query timeouts and ensure data completeness.
Why Chunked Extraction Exists
NetSuite's GL query APIs impose practical limits on response size and execution time. When you request transaction-level detail across a two-year date range for a mid-size company, the query either times out, returns a truncated result set, or triggers rate limiting. Any of these outcomes produces an incomplete extract -- and incomplete GL data is worse than no data at all, because the totals look plausible but do not reconcile.
VersionForge solves this by breaking the extraction into fiscal period chunks, processing each period as an independent, self-contained query.
How Period Chunking Works
Resolve the fiscal calendar
VersionForge reads your NetSuite fiscal calendar configuration to determine the exact start and end dates of each accounting period within your selected date range. This handles non-standard calendars (4-4-5, 4-5-4, 13-period) correctly.
Queue period extractions
Each fiscal period becomes a separate extraction job. Periods are queued in chronological order. The dashboard shows every period in the queue with its status.
Extract each period independently
For each period, VersionForge executes a scoped GL query filtered to that period's date boundaries. The query pulls transaction-level detail: account, department, class, location, amount, memo, and posting date. Pagination is handled automatically within each period.
Validate and stage
After extraction, the period's data goes through trial balance validation (see Trial Balance Validation). If validation passes, the data is written to the staging area. If it fails, the period is flagged and the loader moves to the next period.
If a single period fails extraction or validation, the remaining periods still process. You do not lose progress on a 24-month load because month 7 had an issue. Fix the problem and re-run only the failed period.
Account Mapping
NetSuite's chart of accounts does not map one-to-one to your target system's dimension structure. The GL History Loader uses a configurable account mapping table to translate between the two:
- NetSuite account number maps to a target account code (e.g.,
6010maps toOPEX_TRAVEL). - Subsidiary and department segments map to target cost center or entity dimensions.
- Unmapped accounts are flagged during staging so you can add mappings before loading.
You configure the account mapping table in GL History Loader > Settings > Account Mapping. The mapping supports wildcards for ranges (e.g., 6000-6999 maps to a single rollup) and one-to-many splits for allocation accounts.
Period Format Translation
NetSuite and your target system likely use different period identifiers:
| System | Format Example |
|--------|---------------|
| NetSuite | Jan 2025, Feb 2025 |
| Adaptive Planning | FY25-01, FY25-02 |
| Pigment | 2025-01, 2025-02 |
VersionForge translates period codes automatically based on your target connector's configuration. You define the target period format once during setup, and every extracted period is relabeled before staging.
If your fiscal year does not start in January, make sure your fiscal year start month is set correctly in the GL History Loader settings. This ensures that FY25-01 maps to the correct calendar month.
Performance Expectations
| Company Size | Periods | Rows per Period | Total Extraction Time | |---|---|---|---| | Small (single subsidiary) | 24 | ~2,000 | ~10 minutes | | Mid-market (3-5 subsidiaries) | 24 | ~15,000 | ~45 minutes | | Enterprise (10+ subsidiaries) | 36 | ~50,000+ | 2-4 hours |
Extraction time depends on NetSuite instance performance and API concurrency limits. VersionForge respects rate limits and automatically backs off when throttled.