NetSuite Vendor Bill Variances: Clear Accrued Purchases

Executive Summary

NetSuite vendor bill variances explain differences between the value received and the value billed that remain in Accrued Purchases. With Advanced Receiving, the native process generates journals that transfer eligible differences to configured variance accounts, supporting clearing without an ad hoc manual journal. A reconciled account can retain supported receipts awaiting invoices; its entire balance need not disappear. The controller's objective is a complete explanation by purchase-order line, with legitimate timing items distinguished from eligible variances and transaction exceptions. ^{[1] [2] [3]}

The central decision is the comparison population. Match Bill to Receipt supports comparison at the vendor-bill line against associated receipts, including purchasing that crosses periods. The alternative compares transactions associated with a purchase-order line. These methods require different completion and linkage checks. Oracle's posting procedure describes closed lines for the purchase-order selection list; the conceptual guidance requires separate attention to completion and receipt associations. Teams should confirm account eligibility before treating a missing line as an accounting difference. ^{[3] [4]}

Price, quantity, and foreign exchange (FX) are distinct explanations. This report's independently calculated, fictional equal-quantity example has receipt credits of $1,240.00, bill debits of $1,455.50, and a $215.50 debit residual. Workpaper decomposition produces $189.85 price variance and $25.65 FX variance. These are illustrative calculations using Oracle's documented framework, not observed NetSuite output. No sandbox was available. Examples combining quantity and FX changes require separate sandbox validation. Accounting classification also requires the applicable inventory policy. ^[5]

The recommended close design establishes scope, proves the source population, reviews exceptions, posts a controlled batch, and ties the journals back to the ledger before locking the period. Audit guidance emphasizes accurate, complete journal populations and supporting evidence; the operational controls here adapt those principles rather than imposing an auditing standard on every business. ^{[6] [7]} Traceability matters as much as the account total: practitioner implementations demonstrate purchase-order-line identifiers connecting receipts, bills, and generated entries. Manual clearing entries should follow a documented accounting decision after the cause is understood. ^[8]

Introduction and Background

A controller reviewing Accrued Purchases after billing needs to answer a precise question: does the balance represent goods awaiting billing, a completed purchasing cycle with a valuation difference, or an exception in the transaction chain? Practitioner guidance describes residuals arising when purchasing quantities or prices differ. The account therefore needs an explanation tied to business events, rather than a target balance chosen in isolation. ^[9]

This guide addresses post-transaction reconciliation for controllers, accounts payable (AP) managers, inventory accountants, administrators, and implementation consultants. It concentrates on deciding which population should be compared, proving what remains, and preserving a reviewable clearing trail. A receipt awaiting a later invoice can remain a valid reconciling item. An explanation should specify the outstanding event, its owner, and the evidence that will resolve it. ^[2]

The operational definition of reconciled used here is a report recommendation: the detailed population agrees to the general ledger (GL), each residual has a supported classification, and each action has an accountable owner. This follows the journal-population accuracy and completeness principle in Public Company Accounting Oversight Board (PCAOB) staff guidance. It does not imply that an exported spreadsheet has independently established the accounting treatment. ^[6]

A useful reporting analogy appears in Netgain's own NetClose documentation: its subledger reconciliation works best when the subledger represents the entire expected GL balance. That is an add-on design principle, not evidence that a particular native search is complete. (Source: support.netgain.tech) Similarly, a review tolerance should consider qualitative circumstances as well as amount, consistent with the risk-based framing in Securities and Exchange Commission (SEC) staff guidance. ^[10]

This edition reflects documentation retrieved on October 23, 2026. Configuration choices and examples require testing in the reader's account. The practical sequence follows the purchase order, receipt, bill, and variance-account flow described in Citrin Cooperman's walkthrough, while Oracle documentation supplies the authoritative native mechanics. ^[3]

Transaction Anatomy and Variance Taxonomy

A purchase order (PO) records the purchasing instruction. Oracle states that the PO has no accounting impact before items are received. With receipt and billing separated, the receipt and vendor bill become distinct accounting events. This makes a line-level bridge more useful than comparing document totals alone. ^[11]

Table 1 summarizes the illustrative inventory purchasing chain. It assumes an ordinary inventory receipt and omits tax, freight, returns, and other account-specific effects. The basic posting relationships follow Oracle's receiving explanation; the variance transfer is also described in the practitioner walkthrough. ^[3]

The table is a bridge for proving Accrued Purchases. It does not establish that inventory valuation is correct. Oracle explains that changing a vendor bill's cost does not update item costing in the documented receipt-driven process. A cleared accrual and a correctly valued inventory balance therefore require separate checks. ^[12]

Standard costing adds an important distinction. Oracle describes inventory assets at standard cost and purchase-price differences recognized at receipt. Protelo likewise describes standard-cost variances as differences between fixed and actual costs. A receipt-time purchase-price variance and a later bill-price variance answer different questions; the workpaper should identify the event and account rather than relying on a similar account label. ^{[13] [14]}

Gurus Solutions also distinguishes bill-variance posting from inventory valuation. Its practitioner explanation reinforces why a variance journal should not be assumed to revalue remaining stock or reconstruct historical cost of goods sold. Any required inventory correction needs its own approved treatment and account-specific impact analysis. ^[15]

For entities applying International Financial Reporting Standards (IFRS) and International Accounting Standard (IAS) 2, the IFRS Foundation describes inventory cost as including purchase and other qualifying costs, and measurement at the lower of cost and net realisable value. Those principles explain why system clearing alone cannot determine capitalization or expense classification. Other reporting frameworks require their own authoritative analysis. ^[5]

Keep other accrual processes visible in the design. Charted's separate Accrual Automation documentation describes expense-type accounts as its default scope. Where an additional accrual module operates, establish its account boundaries and interaction with purchasing accruals before assuming the populations are interchangeable. That recommendation concerns coexistence controls, not native vendor-bill variance functionality. ^[16]

Choosing the Comparison Method

Inspect the transaction-line method and the item accounts separately. Item records provide Bill Price Variance, Bill Quantity Variance, and Exchange Rate Variance accounts. Verify the configured destinations and inspect Match Bill to Receipt on the actual PO line; a current default does not establish an older line's setting. ^[17]

Table 2 compares the native methods. Citrin Cooperman describes the same distinction between bill-line matching and PO-line posting. The recommendations in the final column are control design choices, not additional system eligibility rules. ^[3]

The choice determines what the calculation sees. Oracle permits matched purchase-order lines to generate variances whether open or closed and requires receipt linkage in that procedure. A bill covering a subset of deliveries therefore needs an intentional receipt association. Matching by supplier name, invoice total, or calendar proximity is insufficient evidence of the documented comparison population. ^[1]

For the unmatched method, a documentation discrepancy remains important. Oracle's conceptual page permits fully received and billed lines, with closure required for incomplete lines. Its procedural page describes the Purchase Order filter as showing closed lines with a variance. These statements should be retained as a testing question rather than silently harmonized into a universal eligibility rule. Record the line status and observed selection-list behavior in the sandbox evidence. ^[4]

The documented menu is Transactions > Payables > Post Vendor Bill Variances. Oracle instructs the user to verify the journal posting period and date. A transaction date, an operational completion date, and the journal's posting period should each be captured deliberately. Saturotech's walkthrough also includes choosing the posting period. A documented appearance in a processing list is not an approval conclusion. Oracle notes that pending-approval bills appear for quantity allocation and offers an Include Bills Without Receipts option. Neither statement by itself establishes that an unapproved or unlinked bill has the same posting treatment as a fully supported matched case. Exclude unresolved cases from the approved batch until their behavior is demonstrated. ^{[4] [9]}

For either method, retain the intended population and the reviewer decision before posting. PCAOB staff's emphasis on supporting evidence provides a useful control principle. A specialist's custom reconstruction of PO-line relationships illustrates the value of explicit lineage, but custom tools and native posting should remain clearly identified in the evidence. ^{[6] [8]}

Price, Quantity, and Exchange-Rate Calculations

Oracle identifies separate price, quantity, and exchange-rate variances. Its journal documentation calculates amounts from associated receipts and bills, aggregating at the PO line when receipt matching is unused and at the matched bill line when it is used. The comparison population must therefore be fixed before a controller calculates an expected result. ^[18]

The following glossary reproduces the documented expressions. VB means vendor bill, IR means item receipt, Qty means quantity, Val means value, and Average FX means the exchange-rate measure used in the expression. The original price expression uses both “VB Value” and “VB Val”; an implementation should confirm their intended equivalence.

• Price: VB Qty * ((VB Val / VB Qty) - (IR Val / IR Qty)) * ((VB Value * VB Average FX)/VB Val). This isolates the unit-price difference using the bill-side FX factor.
• Quantity: (VB Qty - IR Qty)*(IR Val / IR Qty). The published expression contains no explicit exchange-rate multiplier. Its currency units must be established before applying it to a multicurrency quantity mismatch.
• Exchange rate: VB Qty * (IR Val / IR Qty) * (((VB Val * VB Average FX) / VB Val) - (IR Val * IR Average FX) / IR Val). This uses a receipt-price basis and the difference between the bill and receipt FX factors. ^[18]

For an independent workpaper, define weighted unit price as total foreign-currency value divided by quantity. Define weighted FX as total base-currency value divided by total foreign-currency value, using the same population. These definitions make the arithmetic reproducible. Oracle's aggregation prose lists sums with incomplete mathematical notation; these explicit workpaper definitions are analytical choices to validate against actual journals, not a claim that every account implements an independently reconstructed algorithm identically.

Currency direction must be stated: the example below uses base-currency units per foreign-currency unit. Do not mix a displayed reciprocal rate with that convention. IAS 21's public overview identifies exchange-rate selection and reporting its effects as central accounting questions; it does not resolve the source documentation's quantity-formula ambiguity. ^[19]

The native variance process should also be kept distinct in the workpaper from settlement FX, period-end currency accounting, and inventory costing decisions. Establish the relevant accounting policy before choosing classification or offset accounts. This is a scoping recommendation informed by IAS 21's subject matter, not a detailed recognition rule taken from its public overview. ^[19]

Finally, calculations need transaction support. A workbook that produces an attractive total without proving the quantities, values, and associations remains incomplete evidence. Review precision, detail, and source support before turning the calculation into an automated posting rule. ^[6]

Diagnosing Residual Accrued Purchases

Start with a posting-basis population and identify whether the exception is operational, transactional, configurational, or an already-posted accounting event. CuriousRubik's practitioner guide lists incorrect receipt links and unmatched credits among possible explanations. These are diagnostic categories, not evidence of a product defect or of their prevalence. ^[2]

The following decision tree is a recommended review sequence. Each branch needs a cause, an owner, and supporting evidence.

• Receipt awaiting bill: Confirm the goods received, supplier invoice status, and expected billing event. Retain the supported timing item.
• Bill awaiting receipt: Confirm whether goods remain in transit, receipt recording is incomplete, or the bill belongs to a different purchasing event.
• Complete cycle with a difference: Compare the included quantities, prices, currencies, and base amounts. Establish whether the selected native method applies.
• Broken or unexpected association: Trace the bill and receipt to their actual source lines. Investigate standalone, duplicated, or differently linked transactions before posting.
• Existing variance journal: Find its signed Accrued Purchases lines, posting period, and any subsequent void, deletion, or reversal effect.
• Account or scope difference: Inspect item accounts, subsidiary, accounting book, period, and reports before proposing an entry.

For receipt or inventory valuation questions, the distinction matters: Gurus Solutions says vendor-bill variance does not post to inventory. An apparent accrued-purchase cleanup issue can therefore contain a separate inventory valuation question. Route that question to the inventory accountant rather than treating the variance account as a universal remedy. ^[15]

Payment status is a different relationship from receipt matching. Opal Creek's settlement-search analysis distinguishes header-level applications from transaction transformation lineage. A paid invoice does not, by that fact alone, prove the relevant receipt relationship. Its examples concern settlement searches; their exact behavior should not be generalized into a universal receipt-matching join. ^[20]

Before treating a residual as real, prove the report. Check completeness against the ledger and inspect a sample of source records. An unsupported reporting omission should be corrected in the report, while an unsupported business transaction requires investigation in the transaction chain. PCAOB's journal-population guidance provides the completeness principle underlying this separation. ^[6]

Prioritization should include amount, age, unusual transaction structure, and recurrence. SEC staff guidance's qualitative-and-quantitative framing supports avoiding an amount-only review policy. A small recurring linking exception can deserve attention even when the current individual balance falls below the controller's numerical review threshold. ^[10]

Then inspect the cutoff. Saturotech explicitly includes journal posting-period selection in its procedure. A variance journal recorded later than the receipt or bill can explain why a historical balance differs from a current transaction-status view. Preserve both the historical balance date and the dates of later resolution. ^[9]

Oracle requires posted variance journals to be voided or deleted before associated transactions can be changed, with the relevant accounting period open and AP unlocked under its posting instructions. A routine reversing journal should not be assumed to remove those source-transaction restrictions. The native recovery sequence must be tested before anyone edits the linked chain. ^[4]

Finally, check aggregation. Opal Creek explains that a link amount and the applying document's entire total are different measures. Repeating an entire document total across several relationships can overstate a reconciliation. The general control objective is an explanation of differences based on complete and accurate processing, consistent with the Government Accountability Office (GAO) reconciliation guidance. ^{[20] [21]}

Designing the Close Control

The following controls are recommendations for a finance team's operating policy. PCAOB, SEC, and GAO materials provide useful principles within their respective scopes; they do not create a universal compliance mandate for all private NetSuite users. Population completeness and supporting evidence remain relevant design objectives for this reconciliation. ^[6]

Set a run cadence from the actual close timetable, receipt and billing volumes, supplier cycles, account materiality, and review capacity. The policy should specify when the population is captured, who can change it, and when final validation occurs. Avoid assigning a universal frequency without examining those conditions. Document the policy, ownership, and exception handling, adapting GAO's documentation principle. ^[21]

Use separate posting eligibility and review thresholds. Eligibility follows the selected method and transaction state. Review thresholds govern who investigates and approves the accounting explanation. Include qualitative triggers, such as unusual account combinations or repeated linkage exceptions, alongside monetary amounts. The SEC staff framework supports that broader risk assessment. ^[10]

A practical control record should contain the following fields:

• Population: Accounts, subsidiaries, accounting books, currency basis, posting periods, and included transaction types.
• Identity: PO, PO line, receipt, receipt line, bill, bill line, and variance journal references.
• Amounts: Receipt credits, bill debits, signed journal effects, residual, and original transaction currency.
• Classification: Timing, eligible price/quantity/FX difference, linkage exception, configuration exception, or unresolved.
• Aging: Defined starting event, elapsed time, expected resolution, and overdue rationale.
• Responsibility: Preparer, operational owner, reviewer, approver, and escalation route.
• Evidence: Source documents, calculation, configuration snapshot, journal trace, and review decision.
• Period: Original posting periods, proposed journal period, resolution period, and lock status.

This is a proposed evidence schema. Its purpose is to make journal initiation, authorization, recording, and processing reviewable, activities expressly included in PCAOB's period-end reporting framework. The schema should be adapted to the organization's risks rather than treated as a prescribed NetSuite record. ^[7]

Separate preparation, approval, and execution where practical. Where staffing makes separation difficult, require a documented supervisory review with enough information to challenge the population and entries. GAO discusses alternative control activities where segregation is impractical. A reviewer should record what was inspected and how exceptions were resolved. ^[21]

Sequence the close deliberately: freeze the evidence population, resolve or classify exceptions, approve the proposed batch, post, reconcile the resulting journal effects, approve the final residual, and then apply the period locks. Keep responsibility for authorization explicit throughout. This sequence is a recommended implementation of period-end process controls. ^[7]

The batch's automatic origin does not remove the need for review. PCAOB staff guidance includes automated journals within its control concerns. Require support for the comparison population and resulting accounts, and confirm that the posted result agrees with the approved batch. ^[6]

For historical evidence, a report must preserve an appropriate time basis. Netgain's documentation distinguishes date-filterable balances from current-state information in its reconciliation design. An export showing only today's status should not be used to silently replace the archived close population. (Source: support.netgain.tech)

Where additional accrual automation exists, document included and excluded accounts separately. Charted's own documentation allows exclusions through internal account IDs. That is a useful example of explicit scope, not evidence that the same controls are automatically active in the native variance process. ^[16]

Safe Cleanup and Reporting Requirements

Begin with a bounded cleanup proposal: selected transactions, expected effects, authorized period, approver, and recovery plan. Document authorization before execution, following the period-end control framework. ^[7]

Make the proposal reviewable before production changes:

• Reproduce: Use a sandbox with representative configuration and transaction relationships.
• Snapshot: Preserve an unchanged export of source records, links, settings, periods, and balances.
• Predict: Calculate journal direction and account effects.
• Pilot: Run a small, explicitly approved batch.
• Trace: Connect generated journal lines to their comparison population.
• Recover: Document supported void, deletion, or reversal steps and required permissions.
• Validate: Reconcile the result against the approved expectation.
• Retain: Archive evidence, approval, output, and the final balance proof.

These are proposed steps, not a claim of sandbox execution. PCAOB staff guidance supports inspecting underlying journal evidence, beyond accepting a statement that a screen was reviewed. ^[6]

Preserve the change trail alongside the balance export. Oracle states that System Notes record changes and cannot be edited by users, scripts, or applications. Verify reviewer permissions when collecting history. ^[22]

Prolecto describes a custom utility that stamps journal lines with the originating PO-line identifier. This illustrates a tracing option; it does not establish that native variance journals universally contain the same custom reference. ^[8]

Manual clearing journal entries (JEs) require a cause and an approved accounting rationale. An offset can reduce the total while leaving transaction relationships unresolved. Follow the recovery restrictions described above. Gurus Solutions makes its receipt-correction discussion conditional on an open period; it does not support blanket historical edits. ^[15]

Define the expected ledger population before selecting technology. Netgain makes completeness of that balance important in its own reconciliation documentation. Apply that design question when specifying a saved search or SuiteQL, NetSuite's query language. (Source: support.netgain.tech)

Join design needs testing. Oracle documents transaction, line, and accounting-line relationships that can duplicate data; its Workbook guidance specifies a path through transaction lines. CuriousRubik similarly cautions against header-only aggregation. Neither establishes a universal executable query. ^{[23] [2]}

The reporting specification should require:

• Posting grain: Debit and credit lines with a tested unique key and book scope.
• Business grain: Source-line identities and verified receipt/bill associations.
• Currency basis: Separate transaction, subsidiary-base, and consolidated amounts.
• Cutoff: Explicit historical-date and posting-period criteria.
• Journal state: Documented handling of posted, voided, and reversed activity.
• Completeness: Detail totals tied to the ledger before and after aggregation.
• Exceptions: Unlinked entries retained rather than lost through joins.
• Access: Recorded role, permissions, books, and data source.

Use the Records Catalog to inspect fields, joins, and permissions; Oracle says visibility depends on role. Executable SQL is omitted because the account schema and results have not been tested. ^[24]

Distinguish settlement links from transformation lineage, following Opal Creek's reporting example. Preserve historical filters, following the date-basis consideration in Netgain's documentation. ^[20] (Source: support.netgain.tech)

Validate source records and ledger totals. ^[6] Oracle distinguishes transaction-date and posting-period filters for reports; validate saved-search or query criteria explicitly rather than assuming a report preference changes them. ^[25]

Data Analysis and Evidence

Partial Receipts, Multiple Bills, and FX (Hypothetical Example)

The following inputs are fictional, with a single PO line, a single subsidiary and accounting book, and a common foreign transaction currency. Rates mean base currency per foreign-currency unit. Receipts and bills each total 100 units, deliberately making the quantity difference zero. The calculations apply the documented price/FX framework using explicitly defined weighted workpaper measures. They have been checked with exact rational arithmetic, not executed in NetSuite. Assume a closed PO line with Match Bill to Receipt clear.

The PO-line equation is receipt credits + bill debits + posted variance journals = residual, using signed amounts. Separately include any other posted entries.

Table 3 presents the signed Accrued Purchases bridge. Debits are positive; credits are negative. The proposed variance rows represent the workpaper expectation for clearing this debit residual, not a posted journal or approved classification.

The bridge is an independent calculation: −1,240.00 + 1,455.50 − 189.85 − 25.65 = 0.00. Bill foreign value is 1,150.00; dividing its base value by that amount gives the weighted bill FX. Price variance is 100 × (11.50 − 10.00) × (1,455.50 / 1,150.00) = 189.847826.... FX variance is 100 × 10.00 × ((1,455.50 / 1,150.00) − 1.24) = 25.652174.... Rounding these components to cents preserves the stated total. The expected clearing entry credits Accrued Purchases 215.50 and debits the assigned price account 189.85 and FX account 25.65, subject to accounting approval.

For a separate domestic-currency quantity illustration (Hypothetical Example), assume receipt quantity 100, receipt unit price 10, billed quantity 105, billed unit price 11, and FX equal to 1. Original arithmetic produces price variance 105, quantity variance 50, and total difference 155, matching 105 × 11 − 100 × 10. The quantity expression is applied without a multicurrency conversion assumption.

What the Numbers Prove

The examples prove arithmetic under the stated assumptions. Production evidence must additionally prove the included transactions, selected method, journals, and accounting classification. PCAOB's precision-and-detail principle supports retaining those inputs alongside the result. ^[6] GAO's reconciliation principle likewise supports explaining differences rather than relying on an apparently satisfactory ending total. ^[21]

Historical proof needs a reproducible cutoff; Netgain's own date-filtering guidance illustrates that design requirement. (Source: support.netgain.tech) Operational traceability also benefits from explicit source-line identity, as Prolecto's custom approach demonstrates. ^[8] For linked amounts, Opal Creek's distinction between a specific application and a whole-document total supplies a further reason to validate aggregation before trusting a balance. ^[20]

Oracle's separate published example records a receipt credit of $229.32 and a bill debit of $378.00, leaving $148.68. Independent subtraction reproduces that residual. These published figures are separate from the fictional scenario above. ^[1] Inventory-cost classification remains a separate IAS 2 analysis. ^[5]

Implications and Future Directions

A stable process makes the explained residual the principal close deliverable. The final account proof should preserve the ledger balance, supported timing items, eligible unposted differences, and unresolved exceptions. A numerical threshold should guide review capacity while leaving qualitative escalation available, consistent with the SEC staff's risk framing. ^[10]

The accounting and system decisions should proceed together. IAS 2's public overview helps frame inventory-cost questions for IFRS reporters. For United States generally accepted accounting principles (US GAAP), the Financial Accounting Standards Board (FASB) identifies its Codification as authoritative and cautions that Accounting Standards Updates are not themselves authoritative standards. This research did not retrieve current Codification text establishing a universal capitalization rule for these variances. A qualified technical accountant should determine treatment under the applicable framework. ^{[5] [26]}

Involve a NetSuite specialist when the team cannot reconstruct line relationships, explain eligibility, reproduce journal calculations, or design a complete report. Prolecto's custom lineage implementation illustrates the type of technical tracing that may be needed; Protelo's standard-cost discussion illustrates why costing configuration belongs in the diagnostic scope. These examples establish possible workstreams, not an endorsement or a claim that customization is always necessary. ^{[8] [14]}

Houseblend's perspective here is that of a NetSuite implementation and administration adviser. The decision matrix compares native posting methods; it is not a comparison of consulting providers. The finance team retains responsibility for accounting policy and approval, while technical work should produce reproducible evidence for that review.

Future automation should begin with explicit boundaries and retained authorization. Charted's documented account exclusions offer an example of scope configuration in a separate accrual product. ^[16] The period-end control framework supports clear responsibilities for processing and approval, while GAO's documentation principle supports retaining the design and its changes. Automation should reproduce a proven reconciliation before expanding posting volume. ^{[7] [21]}

Conclusion

NetSuite vendor bill variances belong inside a controlled purchasing reconciliation. The useful result is an Accrued Purchases balance that can be explained from its underlying transactions. Supported receipt-to-bill timing items can remain; they should have owners, evidence, and expected resolution events. A zero total alone is an incomplete operating objective. ^[2]

The controller should first establish the comparison population, then confirm the line's actual settings and relationships. The workpaper should distinguish price, quantity, and FX explanations from transaction or reporting exceptions. The fictional examples show how to make the arithmetic reproducible, while their stated limitations identify what remains for account testing and professional accounting judgment.

The close procedure should preserve authorization, source support, journal traceability, and final validation. Clear responsibilities for initiating, authorizing, recording, and processing entries provide a useful foundation for that design. ^[7] Review should establish both the completeness of the population and the support for selected journals, using the applicable control framework and the organization's own risks. ^[6]

Manual clearing entries require the same discipline: explain the cause, approve the treatment, preserve the transaction trail, and validate the resulting account proof. For currency differences, establish the rate convention and accounting scope explicitly. ^[19] A repeatable reconciliation is achieved when the next close can reproduce the explanation, identify what changed, and resolve exceptions without losing the connection between purchasing events and the ledger.