Overview
As of Date accounting is the foundation of how Smart Adjustments maintains financial accuracy despite changing upstream data. This article explains the core concepts and why this approach matters for e-commerce accounting.
What You’ll Learn
What Point in Time accounting means in the context of e-commerce
Why traditional accounting systems struggle with data drift
How Blue Onion’s snapshot approach solves these challenges
The relationship between as-of dates and booking dates
Key Concepts
As-of Date Accounting: An accounting approach that captures and preserves the state of data as it existed at specific moments, allowing you to view and book entries based on what was known at that time rather than only seeing current data.
Booking Date: The date when a journal entry is marked as final and used in your General Ledger. A reference point for detecting future changes. A booking date is an As-of Date that you have chosen to use for recording and calculating future adjustments.
As-of Date: The date representing which data snapshot you’re viewing, allowing you to see journal entries as they appeared at historical points in time.
The E-Commerce Data Challenge
How Commerce Platforms Update Data
Unlike traditional business transactions that remain static once entered, e-commerce platforms continuously update transaction data:
Order Example:
- Day 1: Order placed with estimated discount, shipping and tax
- Day 2: Discount adjusted
- Day 4: Shipping charge to the customer removed from order
Why This Creates Accounting Problems
Traditional Approach Limitations:
1. Lost History: Viewing only current data means you can’t see what was known when you originally booked entries
1. Unexplained Variances: When numbers change, there’s no clear record of what shifted and when
1. Reconciliation Nightmares: Your GL shows one number, but the platform now shows something different
1. Audit Trail Gaps: Can’t prove what data was available at the time of booking
How Point in Time Accounting Works
The Snapshot System
Blue Onion captures and preserves data snapshots at regular intervals:
Timeline of Data Snapshots:
Oct 9, 10:30 AM → First snapshot when order arrives
Oct 10, 12:45 PM → Second snapshot after platform update
Oct 11, 11:20 AM → Third snapshot with additional data
[Current] → Most recent snapshot with latest data
The As-of Date Selector
The as-of date selector allows you to “time travel” through these snapshots:
1. Select a Historical Date: Choose any date from when data first appeared through today
1. View That Snapshot: See journal entries exactly as they would have appeared on that date
1. Compare Across Time: Navigate between dates to see what changed
1. Drill into Details: Click through to transaction-level data from any snapshot
Booking Dates: Your Reference Points
What Is a Booking Date?
When you book a journal entry, Blue Onion marks that specific snapshot as “booked” and associates it with that date. This creates a reference point that Smart Adjustments uses to detect future changes.
Key characteristics:
Tied to a specific as-of date snapshot
Becomes the baseline for adjustment detection
Can be pushed to your ERP (for Subledger users)
Preserved in history even if data later changes
The Relationship Between As-of and Booking Dates
Example Flow:
1. Oct 9: Order arrives in Blue Onion (first as-of date)
2. Oct 10: You book the journal entry (booking date = Oct 10, as-of date = Oct 9)
3. Oct 12: Amazon updates the order details (new as-of date available)
4. Oct 13: Smart Adjustments detects difference between booked snapshot and Oct 12 snapshot
5. Oct 13: Adjustment journal entry generated showing the delta
The booking date anchors what you told your GL, while the as-of date shows what data you had available when you made that decision.
Data Drift Detection
How Blue Onion Detects Changes
After you book a journal entry, Blue Onion continuously compares:
**Booked Snapshot** (what you sent to GL)
vs.
**Latest Snapshot** (current platform data)
When differences are detected:
1. **Calculate Delta**: Determine the exact difference between booked and current values
1. **Generate Adjustment**: Create an adjustment journal entry with only the changes
1. **Flag for Action**: Display in Booking Management with orange “adjustment” indicator
1. **Optionally Auto-Book**: For ERP Subledger users with cadence enabled, automatically push to GL
### What Changes Are Tracked
Smart Adjustments monitors changes to:
- **Revenue amounts**: Product value, shipping, tax
- **Fees**: Payment processor fees, platform fees
- **Payment details**: Payment processor assignments, settlement data
- **Account allocations**: Shifting from “unknown” to identified accounts
- **Refund impacts**: Retroactive refunds affecting original orders
## Real-Life Scenario: Amazon Data Drift
Let’s walk through a complete example:
### Initial State (Oct 9, 11:00 AM - First As-of Date)
**Order Details:**
- Amazon order for $50,000
- No payment processor identified
- $22,000 allocated to “Unknown”
- Deferred revenue booked
### After Booking (Oct 10 - Booking Date)
You review the journal entry using Oct 9 as your as-of date and book it to your GL. Blue Onion marks this snapshot as booked.
### Platform Update (Oct 11, 2:30 PM - New As-of Date)
Amazon provides additional data:
- Order value now $67,000
- Stripe identified as payment processor
- Unknown allocation reduced to $5,000
- Amazon Seller amount increased to match
### Adjustment Detection (Oct 12)
Blue Onion compares:
|Account |Booked (Oct 9)|Current (Oct 11)|Delta |
|-------------------------|--------------|----------------|--------|
|Deferred Revenue - Amazon|$50,000 |$67,000 |+$17,000|
|Deferred Revenue - Stripe|$0 |$0 |$0 |
|Unknown Allocation |$22,000 |$5,000 |-$17,000|
An adjustment journal entry is generated showing the $17,000 shift from Unknown to Amazon Seller.
### Result
- Your original booking remains in history unchanged
- The adjustment entry captures the exact delta
- Your GL now reflects current platform data
- Complete audit trail explains the change
## Benefits of This Approach
### For Financial Accuracy
**Eliminates Discrepancies**: Your GL always matches current platform data through automatic adjustments.
**Preserves History**: Original bookings remain intact, showing what you knew at the time.
**Enables Reconciliation**: Compare any GL posting to the data snapshot that created it.
### For Audit and Compliance
**Complete Paper Trail**: Show auditors exactly what data was available when you booked entries.
**Explain Variances**: Point to specific data changes with before/after visibility.
**Demonstrate Controls**: Prove your system automatically catches and corrects data drift.
### For Operational Efficiency
**Reduces Manual Research**: No more hunting through platforms to find what changed.
**Automates Corrections**: ERP Subledger users get automatic adjustment bookings.
**Prevents Surprises**: Know about data changes before they affect month-end close.
## Common Use Cases
### Scenario 1: Historical Reconciliation
Your auditor asks: “Why does this October 15 journal entry show different numbers than what’s currently in Amazon?”
**Solution**: Use the as-of date selector to show the journal entry as of October 15, demonstrating the data available at that time. Then show the adjustment entries that captured subsequent changes.
### Scenario 2: Platform Discrepancy Investigation
Your Shopify revenue report doesn’t match your GL for last month.
**Solution**: Navigate through as-of dates to identify exactly when the data changed, what specific orders or payments shifted, and verify that adjustment entries were created to reflect the changes.
### Scenario 3: Proactive Month-End Management
You want to close books but suspect some Amazon data might still be updating.
**Solution**: Review the Booking Management dashboard to see which entries have pending adjustments, book them as a batch, and set a cadence to automatically catch any late-arriving updates.
## Tips & Best Practices
- **Book entries promptly** to minimize the window for data drift, but don’t wait for “perfect” data
- **Review adjustments regularly** to understand patterns in how different platforms update data
- **Use consistent as-of dates** when comparing journal entries across periods
- **Set cadences wisely** - daily for high-volume businesses, weekly or monthly for others
- **Communicate with your team** about which as-of date represents your “official” booking standard
## Troubleshooting
**Problem**: I’m seeing adjustment entries but don’t understand what changed.
**Solution**: Click into the adjustment entry, then drill through to the transaction profile pages. Use the journal entry history section to see the side-by-side comparison of original vs. adjusted values.
**Problem**: The as-of date dropdown shows many timestamps close together.
**Solution**: This is normal for active platforms that update frequently. Select the date closest to when you typically book entries. The timestamp shows when that snapshot was captured.
**Problem**: My GL numbers don’t match even after booking adjustments.
**Solution**: Verify that all adjustments have been booked. Check the Booking Management page with action-required filter off to see if there are multiple adjustment entries, and ensure all have been pushed to your GL.
## Related Articles
- [Key Concepts and Terminology](#13-key-concepts-and-terminology)
- [Using the As-of Date Selector](#22-using-the-as-of-date-selector)
- [How Data Drift Detection Works](#51-introduction-to-smart-adjustments)
- [Understanding Adjustment Journal Entries](#53-how-adjustment-journal-entries-work)
## Need More Help?
For additional support understanding Point in Time accounting concepts, contact via the chat in your Blue Onion application or schedule a training session with your Customer Success Manager.