Skip to main content
    ← Back to the knowledge hub

    Accounting from the source

    Why accounting should begin before documents reach the accountant

    Connect requests, receipts, invoices and payment evidence, including partial deliveries, before month-end.

    By Linda Accounting ITPublished 5 minute approximate read

    Imagine a restaurant ordering in chat, accepting deliveries verbally and sending invoices to its accountant at month-end. Fast bookkeeping cannot establish who ordered the goods, whether everything arrived or what was paid. This is an illustrative scenario, not a reported customer result.

    Define the action, evidence and owner at each handoff. Missing information should create a follow-up task rather than becoming an assumption.

    Separate an order, a receipt and a payment

    An order records an agreement to buy; a receipt records what arrived; an invoice records a supplier’s claim; bank evidence records money moving. One record should not stand in for all four, particularly with deposits, partial deliveries and returns.

    ERPNext documents Purchase Receipts as acceptance of goods from suppliers, normally against Purchase Orders, and supports received, accepted and rejected quantities. This illustrates the distinction, not a requirement to choose that software.

    References: [1]

    Agree on one reference and clear ownership

    A starting path is request → approval → order → receipt → invoice review → payment approval → reconciliation. Retain the common reference, actor, time and evidence. Approval to purchase and approval to pay are different decisions.

    A small team may begin with a controlled spreadsheet and consistently named folders. Avoid unrelated references in every department. Changes after approval should retain their reason and history rather than silently replacing earlier evidence.

    Worked scenario: ordered 12 kilograms, received 10

    Suppose an invoice claims 12 kilograms but the receiver confirms only 10. Record the two-kilogram difference and assign purchasing to establish whether the balance will be delivered or the invoice corrected. Do not change the receipt just to make it match.

    The exception needs an owner and follow-up date. Payment follows the confirmed facts and agreement. The responsible accountant must assess accounting and tax treatment; an application status cannot make that determination.

    Use bank activity as a lead, not the whole record

    Matching should allow grouped payments, instalments, deposits and transfers between the business’s own accounts. A single cash outflow does not necessarily represent one expense.

    Credit purchases, petty cash, accruals and unpaid items may not appear in the bank account at that time. Keep document registers and outstanding-work lists alongside bank matching. Bank-led investigation must not imply that off-bank records do not exist.

    Pilot one cycle before expanding

    Choose one purchasing category and one team. Record a baseline for repeated document requests, unresolved-item age and the time to review-ready information. Do not promise a saving without a baseline.

    Acceptance means a new reviewer can trace a reported amount to its request, receipt and explanation of differences without relying on the original operator’s memory—not merely that a report opens.

    A practical starting checklist

    • Collect an example from request through payment evidence.
    • Define the reference, owner and meaning of each status.
    • Test partial receipts, duplicates, returns and grouped payments.
    • Create an exception queue with owners and follow-up dates.
    • Review bank activity and outstanding off-bank records together.

    Apply it to your business

    Faster accounting starts with review-ready facts. Begin with one cycle and let people record what they actually know, rather than replacing every system at once.

    References

    1. Frappe. (n.d.). Purchase Receipt. Retrieved October 1, 2026.

    Numbered references support the attributed statements. Scenarios and recommendations are Linda’s examples, not verified client outcomes.

    This article provides process-design guidance and illustrative examples, not an accounting, tax or legal determination or certification of every software module. Apply it with regard to your business, permissions and actual system scope.