C. Purchase Verification with Ledger & Register

1. What is Purchase and Purchase Tax Data Verification?

Purchase verification means checking whether the total purchase value and tax amounts recorded in the Purchase Register and Accounts match correctly.
This process ensures that all purchases are properly recorded in both systems.

In short, purchase verification confirms:

The total purchase value is the same in Accounts and the VAT Purchase Register.
The tax amounts (VAT on purchase) are also properly matched in both.

2. Purchase Data Flow

Before verifying, we need to understand how purchase data flows in the system. Purchases can be recorded in two ways:

Inventory → Receipt
- For stockable items (food, goods, consumables).
Accounts → Purchase Posting (Manual)
- For services and non-running assets (e.g., consultancy, equipment, maintenance).

👉 These are the only correct entry points that reflect in the VAT Purchase Register.

2.A. Inventory Receipts vs VAT Purchase Register

VAT Purchase Register (Inventory type) always matches the Inventory Receipt total.
Why? Because the register takes parent totals and receipts store child details.

⚠️ Case to note:

Receipt shows data based on Receipt Date, while VAT Register shows data based on Bill Date.
That’s why Bill Date and Receipt Date should not cross months.

👉 Generally, no mismatches occur here, but it’s always good to check.

3. Inventory vs Account Stock-In Data Flow & Cases

We create a Stock Subhead under Accounts (e.g., Inventory, Stock & Inventory).
System posts data from Inventory Module to these ledgers.

For each inventory group:

Stock Value Ledger: Stock of Group Name
Cost Ledger: Cost of Group Name

⚠️ Important:
Stock should only be entered via Inventory → Receipt.
Other methods (manual JVs, RVs, Manual PJVs, etc.) create mismatches because they update ledgers but not physical stock.

3.A. Common Mismatch Cases for Purchases

Case 1: Remaining Purchase Postings
Purchases not yet posted in Accounts.
Always clear pending postings before verification.
Case 2: Manual Transaction Entry (JV/RV)
Updates stock ledger but not physical stock.
Case 3: Manual PJV Entry
Posts purchase in ledger but bypasses inventory module.
Case 4: Wrong Mapping
Example: Food sales accidentally mapped to stock ledger.
Rare, but possible.
Case 5: Inventory Ledger Created Outside Inventory Subhead
If wrongly grouped, totals won’t tally.
Case 6: Non-inventory items booked inside inventory
Example: Service/fixed assets posted as inventory.
❌ Not recommended → very hard to tally later.

4. Inventory Purchase Data Verification (Receipt vs Ledger)

Steps:

Load Receipt report.
Open Ledger Reconcile Report in Accounts.
Apply Filters:
- Subhead: Inventory (or stock subhead name).
- Posting From: GR PURCHASE.
Compare totals.

⚠️ If mismatch:

- Remove Subhead filter → recheck. Maybe stock recorded in non-inventory ledger? (Important).
- Ignore VAT and vendor payments.
- If still not matched → break totals into smaller parts and tally step by step.

5. Receipt Tax vs Account Ledger Tax

VAT on purchases is recorded in VAT on Purchase Ledger (under Current Assets).

Steps:

Open Ledger Reconcile Report.
Select VAT Ledger.
Posting From: GR PURCHASE.
Compare with Purchase Register VAT values.

⚠️ If mismatch:

- Verify bill-wise entries using Excel tools (e.g., SUMIF).

6. Account Purchase Journal Voucher (Manual PJV) vs Account Ledger

Account Purchases directly record in Ledger.
Generally, no mismatch.
Still, auditors compare VAT Purchase Register vs Ledger.

Steps:

1. Load VAT Purchase Register (Purchase Type: Account).
2. Open Ledger Reconcile Report.
3. Filters:
  - Posting From: AC PURCHASE.
  - Only check Assets & Expense Ledgers (exclude VAT Receivable).
4. Compare values.

7. Account PJV VAT vs Account Ledger VAT

VAT is auto-posted by the system.

Steps:

Load VAT Purchase Register (Purchase Type: Account).
Open Ledger Reconcile Report.
Filters:
- Posting From: AC PURCHASE.
- Ledger: VAT on Purchase / VAT Receivable.
Compare both.

⚠️ Rare Case:

- User manually selects VAT ledger instead of system auto-posting.
- Hard to detect, but possible cause of mismatch.

8. Fixed Assets in Inventory Module (Why Restricted?)

8.1 Difference Between Current Assets & Fixed Assets

Current Assets (Inventory): Goods purchased for short-term use or resale (food, beverages, consumables, operating stock). These follow the stock flow formula:

Opening + Purchases – Consumption = Closing

Fixed Assets: Items purchased for long-term use (buildings, machinery, equipment, furniture). These follow accounting rules of capitalization, depreciation, disposal, and revaluation.

👉 Because their nature, treatment, and accounting standards are different, fixed assets should not be managed inside the Main Store (Inventory).

8.2 Problems if Fixed Assets Are Managed in Inventory

If we try to manage fixed assets in the inventory system (Main Store), the following issues arise:

Case 1: Consumption-Based Tracking

Inventory always assumes that goods are “consumed” after issuance.

Example: If a laptop is issued to an employee from Main Store, the system will reduce stock as if it was consumed.

But in reality, the laptop is still part of company assets and should remain in the balance sheet under “Fixed Assets.”

Result → Ledger mismatch between Inventory and Fixed Assets account.

Case 2: Depreciation Handling

Inventory cannot calculate depreciation.

Assets like vehicles or machinery require yearly depreciation entries.

If recorded as stock, the system has no way to reduce value gradually → incorrect asset valuation.

Case 3: Disposal / Write-off

In practice, damaged or obsolete assets may remain in books until approved for disposal.

In Inventory, once issued/consumed, they disappear from stock immediately.

Result → Timing difference between physical asset disposal and accounting records.

Case 4: Value Adjustments (Repairs/Capitalization)

Fixed assets often require cost adjustments (e.g., repair capitalizations, part replacements).

Inventory is not designed to handle incremental value changes.

Example: A generator worth 500,000 has a major repair of 100,000 → in accounts, total value becomes 600,000. In inventory, no such adjustment mechanism exists.

Case 5: Reporting Challenges

Balance sheet requires proper grouping of assets into Pools (A, B, C, D) for depreciation calculation.

Inventory reports cannot generate depreciation schedules or asset pools → auditors cannot verify.

Case 6: Wrong Tally in Ledger Reconcile Report

Inventory posting assumes purchases are current assets.

If fixed assets are included in Main Store, the Ledger Reconcile Report will tally them under “Inventory” instead of “Fixed Assets.”

This causes confusion in financial statements and mismatch in auditor verification.

8.3 Suggested (But Limited) Workaround

If client insists on tracking fixed assets inside the system:

Method:

Create a separate store named Fixed Assets Store.

Create groups like Pool A, Pool B, Pool C, Pool D, mapped to Fixed Asset account heads item wise.

Purchases of assets go into this store, separate from Main Store.

⚠️ But even with this method:

Depreciation must still be calculated manually in accounts.

Clients often fail to maintain mapping correctly → assets get mixed into expense/inventory accounts.

Asset disposal timing is not synced between physical records and system posting.

Value increases (repairs, capitalizations) cannot be adjusted easily.

8.4 Conclusion & Future Roadmap

Main Store should only contain operational consumables, not long-term assets.

Inventory is consumption-based, while Fixed Assets require capitalization and depreciation-based accounting.

Mixing them creates tally mismatches, reporting issues, and audit complications.

✅ Therefore, the Inventory Module is restricted to operational stock only.
✅ For proper handling, a dedicated Fixed Assets Module will be developed, with features like:

Asset pool management.

Automated depreciation calculation.

Disposal & revaluation handling.

Integration with balance sheet reporting.

👉 This way, auditors, accountants, and clients can clearly separate operational inventory from capital assets, ensuring both compliance and clarity in reports.

9. Final Notes

Always verify in total first.
If mismatch → break data into smaller groups until the issue is found.
Understand the expected data source (Register vs Ledger).
Use Ledger Reconcile Report for explaining to clients:
- Show which voucher created which entry.
- Point out the cause of mismatch.

✅ By following these steps, you can confidently verify Purchase Data & Taxes, identify mismatches, and explain them clearly to clients.

Documented By - Sundar Mishra.