Purchase Order Journal Entry: Does a PO Post to the GL?

A purchase order does not create a journal entry. Issuing a PO is a commitment, not a transaction, so nothing posts to the general ledger on the day you send it. The first real entry comes at the goods receipt: debit inventory or expense, credit a GR/IR or accrued liability account. The supplier invoice then clears that accrual into accounts payable, and payment clears accounts payable into cash.

Last updated July 2026.

That is the short answer, and it holds in SAP, Oracle, Dynamics 365, NetSuite, and QuickBooks alike. The longer answer is worth knowing because the accounts each system uses have different names, the timing of the receipt accrual is configurable, and government and university funds follow a genuinely different rule. Below are the actual entries, what each ERP calls the accounts, and the one case where a PO really does post something.

A purchase order is a commitment, not a liability

When you issue a PO for $40,000 of steel, you have promised to buy something. You have not received it, you do not owe for it, and nothing has changed about what your business owns. Under accrual accounting a liability is recognized when the obligation is incurred, which happens on delivery or performance, not on the promise. So the general ledger stays untouched.

This is why finance teams track open POs as commitments in a separate report rather than on the balance sheet. The money is spoken for from a budgeting point of view, but it is not an accounting event yet. If you need the reporting side of this, the open purchase order report covers how each system surfaces those commitments.

The three journal entries a purchase order actually triggers

Here is the full sequence for a $40,000 inventory purchase, assuming a standard three-way match process.

Notice that the accrual account nets to zero once the invoice posts. That is the whole point of it. It holds the liability for the window between physical receipt and the invoice arriving, which can be days or can be a quarter. The balance sitting in that account at any moment is your goods received not invoiced balance, and reconciling it is a standard month-end job. For the close-specific mechanics, including reversal timing, see purchase order accrual.

Two details change the picture. If you are buying a service rather than goods, the debit hits an expense account directly and there may be no receipt step at all, in which case the invoice posting is the first entry. And if the invoice price differs from the PO price, the difference lands in a purchase price variance account instead of quietly changing your inventory value.

Does a purchase order require a journal entry?

No. A purchase order is a non-posting document in every mainstream accounting system. It records an intent to buy and reserves nothing in the general ledger. The requirement to post arises when the economic event happens, which is the receipt of goods or services. The single exception is encumbrance accounting in governmental and fund accounting, covered below.

What journal entry occurs when a purchase order is created?

None in the general ledger. QuickBooks and NetSuite both treat the purchase order as a non-posting transaction by design, and SAP, Oracle, and Dynamics 365 behave the same way for standard commercial accounting. If your system shows a ledger entry at PO creation, you are almost certainly looking at either an encumbrance posting or a prepayment, not the purchase itself.

Is a purchase order an asset or a liability?

Neither. It is an off-balance-sheet commitment. Nothing is owed until the supplier performs, and nothing is owned until the goods arrive, so a PO fails both definitions. Large outstanding commitments can be disclosed in the notes to the financial statements when they are material, but they do not appear on the face of the balance sheet.

Purchase order accounting entries by ERP

The logic is the same everywhere. The account names are not, and that is what makes the question hard to search.

SAP

SAP runs this through GR/IR, the goods receipt / invoice receipt clearing account, which is determined by transaction key WRX in automatic account determination. Posting the goods receipt in MIGO debits the stock account or the consumption account and credits GR/IR as an open item. Posting the invoice in MIRO debits GR/IR and credits the vendor payable. When quantity and value agree, the two open items clear against each other and the GR/IR account balances to zero for that line. Anything left sitting there is either a receipt with no invoice or an invoice with no receipt, which is exactly what a GR/IR aging analysis is looking for. Teams moving PO data into SAP will find the load side covered on purchase order to SAP.

Oracle Fusion Cloud

Oracle handles it in Receipt Accounting, which recognizes the liability to the supplier when goods interface over from Receiving. The timing depends on the destination type. Inventory destination receipts are always accrued on receipt. Expense destination receipts are accrued either on receipt or at period end, depending on how you configured it. If you chose period end, the Create Uninvoiced Receipt Accruals process generates the accrual entries for receipts with no invoice yet, and those entries reverse automatically in the following period. The Receiving Inspection account is the intermediate account in the receipt flow. The import path for PO data is on purchase order to Oracle.

Microsoft Dynamics 365 Finance

Dynamics 365 posts to the ledger at two points on a purchase order, the product receipt and the invoice. For the product receipt to post at all, you need Post product receipt in ledger switched on in Inventory and warehouse management parameters, plus Post physical inventory and Accrue liability on product receipt on the item model group. When that is configured, the receipt debits the Purchase expenditure, uninvoiced posting type and credits Purchase, accrual, which is the liability account. Posting the vendor invoice then debits Cost of purchased materials invoiced and reverses the uninvoiced amounts. If none of those checkboxes are set, the receipt posts nothing and the invoice is your first entry. This trips people up regularly, because two companies on the same product can show completely different behavior on the same transaction.

NetSuite and QuickBooks

Both keep the purchase order out of the ledger entirely. In NetSuite the item receipt and the vendor bill carry the accounting impact. In QuickBooks the PO is a non-posting transaction that exists to be matched later, and the entries appear when you convert it to a bill or an expense. Neither one gives you a receipt accrual with the configurability of SAP or Oracle, which is why smaller finance teams often book the unbilled-receipt accrual manually at close.

The exception: encumbrance accounting

Governments, school districts, and public universities do post something when the PO is issued, and this is the source of most of the confusion on this topic. Under budgetary accounting, issuing a purchase order records an encumbrance that reserves part of an appropriation so the same dollars cannot be committed twice. The entry debits Encumbrances and credits Reserve for Encumbrances, or the equivalent budgetary control accounts your state uses.

Two things matter about these entries. They live in budgetary accounts, not in the GAAP financial statements, so an encumbrance never appears as a liability on a governmental fund balance sheet. And they reverse when the goods arrive and the real expenditure or payable is recognized, at which point the normal entries above take over. Outstanding encumbrances at year end affect how fund balance is classified rather than what is owed. Dynamics 365 supports this pattern directly, posting pre-encumbrances from purchase requisitions and encumbrances from PO confirmation through posting definitions.

Where these entries go wrong

The accounting is simple. Keeping it clean is not, and the failures are predictable.

An aging GR/IR or GRNI balance is the most common one. Every line in it is a receipt whose invoice never arrived, an invoice posted against the wrong PO, or a quantity that was received in the system but not in reality. Left alone it quietly overstates liabilities. Second is the price mismatch, where a PO says $12.40 a unit and the invoice says $12.85, and whether that lands in variance or in inventory depends on your costing method. Third is the receipt that was never entered, which leaves an invoice with nothing to match against and stalls the whole three-way match.

All three are data problems before they are accounting problems. You cannot reconcile what you did not capture accurately, and in most AP departments the PO data still enters the system by hand from a PDF.

Getting the numbers out of the documents

Everything above depends on knowing what was ordered, at what unit price, in what quantity, on a specific date. When purchase orders arrive as PDFs, scans, or photos from suppliers and customers, that detail gets retyped, and every retyped digit is a future reconciliation item. Extracting the header and the full line-item grid straight from the document removes that step. The tool at the top of this page returns the PO number, supplier, dates, terms, and every line with quantity and unit price in about ten seconds, as Excel, CSV, or JSON.

For long orders where the line grid is the hard part, see purchase order line item extraction. To clear a backlog before a close, bulk purchase order upload handles batches. And if the output needs to land in your ERP rather than a spreadsheet, how to import purchase orders to an ERP walks through the load path for each major system.

One last practical note on the payment entry, which is the only one nobody argues about. It is also the entry that has to agree with the bank, so month-end goes faster when the statement is something you can sort and filter rather than a PDF you scroll. Converting it to a spreadsheet you can actually reconcile against takes the guesswork out of tying the cash side back to what was paid.

Quick reference

• PO issued: no entry, commitment only (except encumbrance accounting)
• Goods received: debit inventory or expense, credit GR/IR or accrued liability
• Invoice posted: debit GR/IR or accrued liability, credit accounts payable
• Payment issued: debit accounts payable, credit cash
• Price difference: to purchase price variance, not to inventory, under standard costing

If you are documenting this for a policy or an audit walkthrough, the surrounding process is covered in the purchase order to invoice process and the document itself is broken down field by field in purchase order fields.