Purchase Invoice (Internal)

Record the bills your suppliers send you. In the standard purchase flow it is this document, not the GRN, that books the stock in and posts the supplier liability, the purchase and the input tax — and it is the only document that writes an item’s last purchase cost.

Overview

The Purchase Invoice (Internal) applet records the bills your suppliers send you. An accounts-payable clerk opens it to key in a supplier invoice — from scratch or by knocking off (pulling in) a finalised Purchase Order or Purchase GRN — and finalises it. FINAL posts the supplier liability, the purchase and the input tax to the General Ledger and books the invoiced quantities into stock. The invoice is then settled from its own Payment tab, by contra against a supplier deposit or credit document, or later through a Payment Voucher.

In the standard BigLedger purchase flow the invoice is the document that moves stock — and it is the only document type in the platform that writes the item’s last purchase cost. The Purchase GRN (Internal) posts nothing at all: both its signums are zero, so it creates no stock movement, no accrual and no journal, which is why the standard flow has no goods-received/invoice-received clearing account to reconcile (the full comparison). If your business needs stock booked at receipt and invoiced later, use the alternative pair Purchase GRN Stock In (Internal) and Purchase Invoice No Stock In (Internal) instead.

Where it fits

Modules: Financial Accounting and Purchasing.

Screens and menus

The applet’s left-hand menu has six workspaces:

File Import and File Export are removed from the menu when HIDE_FILE_IMPORT_MENU / HIDE_FILE_EXPORT_MENU are on, unless the user holds the SHOW_FILE_IMPORT_MENU / SHOW_FILE_EXPORT_MENU client-side permission. No other entry is filtered: Intercompany is in the menu for every user. The SHOW_INTERCOMPANY_PI_SCREEN client-side permission does not gate it — it is read only by the older create column, which + no longer opens — so granting or withholding it changes nothing you can see here.

The edit form tabs

Sixteen tabs, in a default order you can change under Settings > Default Selection > Details Tab Ordering, each with its own HIDE_..._TAB switch. Reading left to right they are Search Document, Main Details, E-Invoice, Account, Line Items, KO For, Delivery Details, ARAP, Payment, Department Hdr, Posting, TraceDocument, Contra, Doc Link, Attachment and Export — and most of them hold exactly what their name says. Four are worth knowing something about before you open them.

Each line on Line Items opens its own sub-tabs — Item Details, Pricing Details, Costing Details (the landed cost and the last price you paid this supplier; needs SHOW_COSTING_DETAILS), Issue Link (ties the line to an issue-tracker ticket) and, with SHOW_BUDGET, Budget Sub Line.

Top action buttons

Configuration

Before you can use it

Applet settings

Settings › Application Settings. The screen is the shared field-configuration screen filtered to this applet, and 162 of its 264 keys are a HIDE_ or an EXPAND_ that hides a field, a tab, a button or a price column, or opens a panel — flip one and you can see what it did within two seconds. The seven below are the ones that change what the applet will let you do, and not one of them is obvious from the screen. How settings are stored and who they apply to.

Four more are worth a sentence rather than a row. External Invoice No (one of the hidden-by-default external references) carries a duplicate warning of its own that needs no setting: leave the box and the applet looks for another purchase invoice with the same number and prints invoice already exist in and that document’s number under it — a warning only, like the reference check. SHOW_ITEM_STOCK_BALANCE, on a purchase invoice, does more than show a column: the line-item search then lists only items with stock above zero at the invoice’s location, so the item you are buying because you have run out of it disappears from the search — switch it off on this applet if a clerk reports “the item isn’t in the list”. ALLOW_EDITING_DOC_REF_DATE makes Doc Reference Date typeable — until it is on the date is display-only, which is what “the date is greyed out and the invoice isn’t even finalised” usually turns out to mean. And the eleven MANDATORY_* keys add a required-field validator to the browser form and nothing else: they change who gets stopped at the screen, never what the API will accept, so they are a data-entry discipline rather than a control.

On the screen and doing nothing

• The SST and WHT enable flags — declared in the model with no control on any screen, and do nothing here. They are the keys a reader hunts for when the question is “how do I switch on withholding tax for supplier invoices?”, and switching them on changes nothing. They are not dead everywhere — a few sales-side applets that carry their own local settings screen do read them — which is how they came to be in a purchase-invoice model at all. What actually controls the withholding-tax picker on a line here is HIDE_WHT_CONFIG_SELECTION, which starts hidden.
• The whole Knock Off Settings screen. The route renders eight knock-off switches (by and for Purchase GRN, Purchase Order, Purchase Requisition and Supplier Delivery Order); the two Copy From Configuration toggles that belong beside them are commented out of the template. It has no menu entry, and none of the eight switches does anything. KO For offers Purchase GRN and Purchase Order whatever they say. If you were told to “turn on knock-off by requisition”, there is no such switch.

And the reverse case, which is the same trap from the other side. The listing reads HIDE_LISTING_BRANCH, HIDE_EINVOICE_NUMBER and HIDE_EINVOICE_DATE from the stored settings, and none of them is declared in the model or offered on any screen of this applet — they take effect only if something else wrote them. Two more listing keys, HIDE_TRANSACTION_DATE and HIDE_AMOUNT_TXN_MAIN_LISTING, are not in the model either, yet do have a toggle on Application Settings (the screen is shared, and offers them to this applet). The same listing also opts in four analysis columns — dimension, segment, profit centre, project — with SHOW_GL_DIMENSION, SHOW_SEGMENT, SHOW_PROFIT_CENTER and SHOW_PROJECT. The settings model is not the list of this applet’s settings, in either direction.

The other settings screens

Settings is eight screens and Application Settings is only the first of them; what each one is for is set out once in the concepts layer, linked above. Four of them matter here:

• Default Selection holds the branch and location a new invoice opens with, the unit-price decimal precision (2–4), the transaction-date logic in the table above, and the order of the edit-form tabs. RESET restores the tab order and clears the other values on the screen — including the transaction-date logic, which goes back to the date you keyed. If your company relies on Finalized dating, set it again after a RESET.
• Personalization › Default Selection is the same idea for you alone — your branch, your location, your horizontal-or-vertical layout. It also offers an item-type filter for the line-item search (DEFAULT_ITEM_SEARCH_ITEM_TYPE) that saves and that no component reads.
• Branch Settings is per branch, stored on the branch record rather than in the applet’s settings, and one of its six tabs is load-bearing: Default Settlement Method decides which settlement methods the Payment tab offers, and a settlement item whose method has no cashbook fails posting with MISSING_CASHBOOK: STL_MTHD [code]. The others are branch rounding, an item-category filter for the line search, the branch’s menu list, its pricing schemes and its printable format.
• Printable Format Settings stores the default format’s guid in PRINTABLE. Without one the print buttons are disabled and the Export tab reports No Default Printable Selected.

Settings in other applets that control this applet

Who can change what

Client-side permissions this applet defines: 66 active codes. Almost all of them do one thing — put back, for one user, a field or column that a HIDE_… setting took away from everybody. The ones worth knowing are the four that do something else:

• SHOW_DISABLE_EDITING_AMOUNT_TXN_SETTING does not affect a document at all. It decides whether the Lock Amount toggle appears on the settings screen — a permission that gates a setting. If you have been told the line amount can be locked and cannot find the switch, this is why.
• ALLOW_LINE_ITEM_EDIT is the exception to the DISALLOW_LINE_ITEM_EDIT setting: switch the setting on and saved lines go read-only for everyone, then grant this code to the few people who may still correct a line. It is the cleanest setting-and-permission pair on this applet: the setting sets the house rule, the permission names the exceptions. The setting starts off, so saved lines stay editable until somebody turns it on.
• SHOW_COSTING_DETAILS and SHOW_LAST_PURCHASE_PRICE put back the costing sub-tab and the last price you paid this supplier. Both hide a control, not the data — the figures are already in the browser. Do not use either as a control over who can see margin.
• SHOW_TRANSACTION_DATE enables the Transaction Date field after finalising — that is the back-dating grant, and it is a permission rather than a setting precisely because you do not want it for everyone.

Dead permission codes: 23 of the 66. Granting any of these does nothing at all: EDIT_CURRENCY_RATE, DISABLE_EMPLOYEE_LOGIN_AUTO_DETECTION, SHOW_CREDIT_LIMIT, SHOW_CREDIT_TERMS, SHOW_CURRENCY, SHOW_BASE_CURRENCY, SHOW_REFERENCE, SHOW_REASON, SHOW_EXTERNAL_REMARKS, SHOW_SOURCE_DOC_NO, SHOW_LOCATION, SHOW_DELIVERY_BRANCH, SHOW_CREATED_BY_DETAILS, SHOW_VALIDITY_DATE, SHOW_SAVE_BUTTON, SHOW_PRINT_BUTTON, SHOW_CLOSE_BUTTON, SHOW_SEND_EMAIL_BUTTON, HIDE_DRAFT_BUTTON, HIDE_CUSTOM_DOC_NO, HIDE_FOREX_DATA_SOURCE, HIDE_EMAIL_PAYMENT_URL_BUTTON, IPI_HIDE_TRACKING_ID_AND_PERMIT_NO.

Three of those deserve naming twice, because they are the ones an administrator reaches for and then trusts:

• EDIT_CURRENCY_RATE looks like the exception to CANNOT_EDIT_CURRENCY_RATE and is not. Lock the rate and it is locked for the treasury team too.
• SHOW_SAVE_BUTTON, SHOW_PRINT_BUTTON, SHOW_CLOSE_BUTTON, SHOW_SEND_EMAIL_BUTTON are not how the action buttons are governed. The live pairs are HIDE_GENDOC_…_BUTTON settings against SHOW_GENDOC_… permissions, and the registry defines the FINAL, DISCARD and VOID members of that family for this applet — but not SHOW_GENDOC_SAVE_BUTTON. The applet loads that code with the others, but the Save button never consults it: it looks at the hide setting alone. So HIDE_GENDOC_SAVE_BUTTON takes the Save button away from everybody and there is no code in this applet’s permission listing that gives it back to anybody. Hide Save deliberately, or not at all.
• SHOW_CREDIT_LIMIT and SHOW_CREDIT_TERMS do not reveal the supplier’s limit and terms; HIDE_CREDIT_LIMIT / HIDE_CREDIT_TERMS hide those fields from everybody with no way back for anyone.

Server-side permissions are the ones that can fail with a 403 and are listed under Before you can use it: read, create, update and delete are targeted by branch, so a user can be confined to the invoices of particular branches — the only control on this page that a browser cannot talk its way around.

Fields

Main Details

The rest of the header is references and dimensions, and each is hideable on its own: Custom Document Number (needs SHOW_CUSTOM_DOC_NO), Doc Short Code, Client Doc Short Code and Client Doc 1–5 No, Source Doc No (Tenant) and Source Doc Short Code (written by a knock-off, never by you), Doc Reference Date (typeable only with ALLOW_EDITING_DOC_REF_DATE — the usual meaning of “the date is greyed out and the invoice isn’t even finalised”), the five External Quotation / Order / Delivery Order / Invoice / Others references and their dates, which are hidden by default and stay editable after FINAL when they are shown, and Tracking ID and Permit No.

Account

Entity Details (supplier code, name, type, identity type and number, currency, status, description, email, phone), Bill To and Ship To addresses and contacts, and Intercompany (the sister company’s Intercompany Branch and this branch’s purchase-invoice intercompany rules, for a purchase invoice that should raise a sales invoice in that company). In select mode a toggle creates a supplier without leaving the invoice.

Line Items

Item Details holds the item code and name, the quantity in base and in the chosen unit of measure with the ratio between them, serial numbers, bin, batch number, batch issue and expiry dates, item remarks and an item reference. Pricing Details holds the standard unit price (from the pricing scheme, inclusive or exclusive of tax, per unit of measure), unit discount and the multi-level discount block, net and transaction unit prices, the tax code and the withholding-tax code, and the five amount columns — standard, discount, net, tax and transaction. Each line also carries its own optional GL code, branch, the four department dimensions and a delivery instruction. Header adjustment, group discount and rounding lines are written by the applet, not keyed.

Three of those carry consequences the screen does not show:

Payment

Settlement method (from Branch Settings), amount, payment date, reference fields (quotation, order, delivery order, invoice, invoice date, others — hidden by default) and, for card methods, card number, name, issuer, expiry, approval code, batch, card type, CVV as configured.

The payment date you key does not survive the save. ENABLE_EDIT_PAYMENT_DATE / ENABLE_EDIT_SETTLEMENT_DATE make the box typeable, but every save sets each payment line’s date back to the invoice’s transaction date, and the cashbook line always carries the invoice’s date. A supplier paid on the 5th against an invoice dated the 28th of last month shows in the cashbook — and in bank reconciliation — on the 28th. To spot it: the payment date reverts when you reopen the invoice. When the money moves on a different day from the invoice, settle it with a Payment Voucher dated that day instead.

Lifecycle and effects

A purchase invoice has a document status (TEMP while the create form is open, then ACTIVE) and a posting status:

FINAL in the applet is enabled when the header form is valid, a supplier is selected, there is at least one line, no serial number is duplicated within the document, the document is ACTIVE and not locked, and the button is not hidden for this user. These are client-side gates. FINAL in the backend rejects a second FINAL with Generic Document has already been posted to FINAL (HTTP 403), a foreign-currency invoice with no exchange rate (Generic Document exchange rate is required before posting to FINAL), a transaction date in a locked period, serial numbers that already exist in the company or that are duplicated or do not match the line quantity, bin and batch quantities that do not match, and — because this applet never switches it off — a line that would take stock below what the location holds. A missing default GL code is not checked here. The journal and cashbook processors run as queued jobs after the status change, so MISSING_DEFAULT_GL_CODE: <code>, MISSING_CASHBOOK and MISSING_GL_CODE fail the job, not FINAL (see Troubleshooting). A foreign-currency invoice is finalised as a base-currency shadow document that carries the posting.

Contra rows are a second request. A row you add on the Contra tab of a draft is not written when you add it: the applet sends any unsent contra rows after the next successful SAVE, and again after FINAL. If that second request fails you see Documents contra unsuccessfully while the invoice itself has saved — or finalised — without the offset. Check the Contra tab (or the ARAP tab’s Contra column) after a FINAL that carried a contra.

Posting proof block

The Posting tab shows five statuses (Journal, Inventory, Membership Points, Cashbook, Tax); TraceDocument shows the journal and inventory rows.

VOID and what blocks it

VOID on this screen is offered only on a FINAL document that is not locked, when HIDE_GENDOC_VOID_BUTTON is off or the user has SHOW_GENDOC_VOID_BUTTON, and when the company’s e-Invoice status is not ENABLED. Pressed, it first checks the invoice for an active Purchase Return and stops with The invoice has already been linked with a purchase return. Past that, the server refuses the void while any document raised from this invoice is still active — a debit or credit note, a conversion, a return — and the screen reports every such refusal as The purchase invoice has already been returned., whatever the linked document actually is. Look at the Doc Link tab for the document to void first. The server refuses a self-billed invoice’s void outright (Unable to void because the company has the E-Invoice enabled); for an ordinary purchase invoice under e-Invoice, hiding VOID is the screen’s rule. To correct a finalised invoice under e-Invoice, raise a Purchase Debit Note when it was billed too high (it lowers what you owe) or a Purchase Credit Note when it was billed too low (it raises it), or, for a self-billed invoice, cancel it through the e-Invoice portal within the LHDN window. A self-billed Purchase Debit Note reaches MyInvois as a Self-billed Credit Note, and a Purchase Credit Note as a Self-billed Debit Note: the e-Invoice names follow the invoice, the BigLedger names follow your ledger.

Knock-off writes a document link (txn_type knock-off) between the source and the invoice, and a source that is fully drawn down no longer appears in KO For. A Purchase Return raised against the invoice writes a RETURN link instead. The KO For button and the backend converter PurchaseGRNToPurchaseInvoiceConverter are two different things and only one of them is a button: see Knocking off a purchase order or a goods receipt and A goods receipt can create this invoice by itself.

What FINAL actually sets off

FINAL is not a save. It is a separate step that changes the posting status and then hands the document to the main posting job, which starts every follow-on job your tenant has switched on. That is the reason a document can be FINAL with no journal: the status change succeeded and a job failed afterwards.

Every finalised document of every type goes to every follow-on job, and each one decides for itself whether it has anything to do. That is the single most useful thing to know about the Posting tab: a blank status usually means a job ran, looked at a purchase invoice, and correctly did nothing.

The ones that act on a purchase invoice:

The rest — coupons, membership points, commerce orders, sales commission, min/max alerts, Peppol, finance charges — subscribe just as hard and find nothing to do.

The company can narrow the list with an include/exclude list of jobs, set by BigLedger, which is how a document can finalise and post nothing at all by configuration rather than by failure.

Unusually for this family, this document type has a file-import job of its own; the purchase credit note and the sales debit note do not, and their File Import menus use the general import instead.

Which chart of accounts this document type gets

A purchase invoice posts through the ordinary purchase journal mapping — creditor, purchase, purchase discount, purchase return, input tax, forex gain and loss — the same one the purchase credit note, debit note and return use. Not every entry in it is used here: nothing on a purchase invoice posts to the discount entry (a line discount is already inside the line’s net amount), and the return entry is the return’s. So the purchase documents can never drift apart: there is no way to give the credit note a different creditor account by configuration at this level. (GRN Stock In and consignment purchases have their own mapping, with not invoiced accounts.)

The one thing that is not frozen is who you owe. The creditor account comes from the supplier’s AR/AP type, and that type is read live at posting time — not from the snapshot on the document. Change a supplier from AP_TRADE to AP_OTHER and the next journal built for an older invoice — a re-run after a failure, or a Repost — uses the new account. That is the deliberate exception to the snapshot rule below. A void is not a new build: its reversal copies the journal as it was posted, so it reverses the old account.

Where the cost on stock comes from

The question this page exists to answer. There are two cost numbers and one invoice writes both of them differently, which is why they disagree.

The moving average. A purchase invoice is one of nine document types allowed to change the value of stock rather than just relieve it proportionally. For those, the running amount grows by the line’s amount and the unit price is then that amount divided by the new balance quantity. Note which amount: the line’s transaction amount, not its net amount and not its net unit price. When the new balance is zero, or the amount comes out at zero, the previous unit price is carried forward unchanged — a deliberate stickiness, so that selling out does not erase what the item cost you.

The last purchase cost. Written only by this document type, and by no other. The figure is the line’s net unit price if it has one, otherwise net amount ÷ quantity, otherwise transaction amount ÷ quantity, and it is written as both the company-wide and the per-location last purchase cost.

If you use the Stock In pair instead, you get no last purchase cost at all. A GRN Stock In maintains the moving average — but the last purchase cost is written only by this document, and in that flow the invoice is a Purchase Invoice No Stock In. Two costing columns in the same report, one of them permanently stale, is the price of that configuration and it is worth knowing before you choose it.

Why “stock in” is not enough

The direction of this document is fixed, not suggested. The money direction is checked on create and update — anything else is rejected as an invalid amount sign, so an integration has to send it — and every line is forced to stock in, on create and on update. There is no setting and no integration payload that can leave a purchase-invoice line moving stock any other way: if you find one, it predates this rule rather than being a second behaviour you can choose.

But the stock job asks for two more things before it writes anything:

1. the line must be a goods line — so header adjustment, group discount, rounding and settlement lines never reach stock, whatever their quantity; and
2. the item behind the line must be an inventory item. A SERVICE or GL_CODE item is not, and a line on one creates no inventory transaction at all — not a zero one.

So “this document type moves stock” is a statement about the document type, not a promise about your line. An invoice made entirely of service lines posts the payable and the input tax and touches no stock balance, correctly and silently. The Posting tab’s Inventory status is how you tell.

What the invoice keeps of the supplier, and what it looks up later

When you pick a supplier, the applet copies thirteen fields onto the document rather than pointing at the supplier record: the supplier code, the name with the chosen contact’s name appended, the status, e-mail, phone, the entity GL code, the identity number and identity type, the entity type, the description, the currency, the e-Invoice tax identification number and the SST number. It also copies the name, e-mail and phone into the Bill To and Ship To blocks, and takes the supplier’s self-billed e-Invoice flag onto the header.

This is the platform-wide entity snapshot, and it is deliberate: a document is evidence of what was agreed, so a supplier who moves premises or changes bank next month does not retroactively change last month’s invoice. Correcting the copy on one invoice corrects that invoice and nothing else — pushing the change back to the supplier record is a separate act in the Supplier applet.

Three things follow that the screen will not tell you:

• Credit Terms and Credit Limit are not in that copy. The two lines that would have put them there are commented out; they arrive through the separate, Purchaser-gated block described in the Fields callout above. If the printed document shows no terms, that is where it went.
• The AR/AP type is not in the copy either, and that is the point. It is read live at posting (see above), so it is the one supplier field whose later value can still change what an older invoice posts to.
• The e-Invoice supplier block is a snapshot of a snapshot. A self-billed submission takes einvoice_supplier_entity_hdr_json first and falls back to the document’s own entity snapshot field by field. The party you self-bill on behalf of is not required to be the account you posted the payable to, and correcting it is done in the e-Invoice block, not by changing the supplier on the invoice.

Knocking off a purchase order or a goods receipt

What has to be true before a source appears. Not “it is FINAL” — that is necessary and nowhere near sufficient. The invoice’s KO For grids are fed from the source document’s open-queue rows, and those rows exist only when the company has an enabled Knock Off Configuration for that pair. Nothing creates those configurations for you, and Purchase Order → Purchase Invoice and Purchase GRN → Purchase Invoice are configured separately — so an empty KO For grid is far more often a missing configuration than a missing source document, and the screen gives you no way to tell the two apart. Check the configuration first.

The mechanics of the outstanding quantity are the same as on the order, and are set out once on the Purchase Order page rather than restated here. Three of its consequences land on this screen:

• The source’s outstanding quantity drops when you tick it in KO For, on this draft — worked out from earlier invoice links only, so an invoice still in draft is already holding it. Each later Save or finalise from the edit screen then recomputes it from the ordered quantity plus the signed sum of every link on the line, of any document type. Undoing a knock-off — voiding the invoice — puts it back.
• A line that reaches zero has its queue row deleted, so a fully invoiced order is recorded by an absence. KO For showing nothing means either “no configuration” or “all done”, and this screen cannot tell you which.
• A company that configured both PO → GRN and PO → Purchase Invoice gets two different answers: KO For counts invoices only and still offers the full order, while the save-time recompute counts receipts and invoices together and can delete a row the other flow still needed. Configure only the flow you use.

What the button does. KO For is a whole-document knock-off, not a line picker: you tick a source document and the applet posts its header guid — a list of them, when ENABLE_MULTIPLE_KO is on — to the backend knock-off endpoint with this document type’s signums. Two details you will otherwise discover the hard way:

• The transaction date is set to today by the knock-off, overwriting the date you keyed on the draft. Combine that with DATE_TXN_LOGIC and the date on the journal can differ twice from the date you typed.
• The lines appear about two seconds after you click, on a fixed timer in the applet, not when the response arrives. A screen that looks like it did nothing usually has not finished.
• The first source’s header replaces the draft’s. The knock-off copies the first ticked document’s company, branch, location, supplier with its billing and delivery details, references 1 to 5 and reference number, currency, remarks, profit centre, segment, project and dimension over whatever you had keyed on the draft, and copies every source’s attachments onto the invoice. Pick the source first and key your own references afterwards, or re-check them before you finalise.
• Several sources must share the supplier and the branch. With ENABLE_MULTIPLE_KO on, ticking two orders or receipts from different suppliers or different branches is refused with The selected documents contain different entities or branches — one invoice per supplier per branch.

When the invoice and the receipt disagree. Nothing blocks it. There is no over-invoicing guard on this screen: the arithmetic simply drives the outstanding quantity to zero or below and the queue row disappears. On price there is no comparison at all — the knock-off copies the source’s prices in and you retype them, and the difference shows up as the moving average moving, not as a warning. If you need a three-way match, it is a report you run, not a control this applet enforces.

There is no GR/IR accrual in the standard pair

The question every accountant asks about a purchase flow, and the answer is unexpected.

The standard Purchase GRN (Internal) has amount signum 0 and quantity signum 0. The journal builder skips every line whose amount signum is zero and the stock processor skips every line whose quantity signum is zero. So the standard goods receipt posts nothing — no stock, no accrual, no journal. It is a record that the goods arrived. There is nothing for the invoice to clear, which is why you will find no goods-received/invoice-received clearing account in the standard flow and should not go looking for one.

Goods received / invoice received exists in BigLedger, in the other pair:

Read that table before choosing a flow, because the choice is not reversible per document. If you need the liability recognised at receipt — because the gap between delivery and the supplier’s invoice spans month-end, and you do not want a month’s purchases missing from the accounts — you need the Stock In pair, and you accept the stale last purchase cost noted above. If receipt and invoice arrive together, the standard pair is simpler and posts once.

A goods receipt can create this invoice by itself

Separately from the KO For button, a company can configure a document flow that turns a finalised goods receipt straight into a purchase invoice: after every FINAL, the conversion job looks for an active, enabled AUTO document-flow configuration from that source type, and creates the invoice.

When the configuration asks for a stock check and the check fails, the document is not converted and not dropped — it is parked for an automatic-conversion retry job to try again.

A sister company’s sale can create this invoice

In a group, a purchase invoice can arrive without anyone keying it: when a sister company finalises a sales invoice that names an intercompany rule, the pairing builds this invoice in your company. You meet it as a document whose description begins Auto Created From and the seller’s invoice number, and it lists under Intercompany › Inbound › Processed beside the sale it came from. The setup that makes it happen is on the Organisation applet.

What it copies. The seller’s goods and service lines, line for line — item, quantity, unit prices, discounts, tax code and tax amount — and the totals, currency, reference and remarks. The supplier is the selling company’s own record, and the branch is the one whose Default Entity Branch is the Intercompany Branch the seller chose. A payment taken on the sale is not carried. Nothing here prices it again: the cost of the goods to you is exactly what the seller typed, so an RM 20,000 sale keyed as RM 2,000 arrives as an RM 2,000 purchase. Check the figures before you finalise.

Its date is when the pairing ran, not the sale’s date. An AUTO rule dates it the moment the sale is finalised; a MANUAL rule dates it the moment somebody confirms the row. A sale dated 31 March and finalised on 2 April arrives dated 2 April — in the next month, on the other side of your month-end. Correct the Transaction Date on the draft before you finalise, bearing in mind that this applet’s transaction-date setting can overwrite it at Final (see Applet settings).

It arrives as a draft unless the rule has Auto Final Target Doc ticked. Until someone finalises it, your company has neither the payable nor the stock, while the seller already shows the receivable — the first thing to look for when the two companies’ balances disagree at month-end. With the box ticked it is marked final at once and handed straight to the posting, without the checks the Final button runs; a missing account then fails the posting and leaves it final with no journal.

Once created it stands on its own. Voiding the sale leaves this invoice where it is, and voiding this one leaves the sale. If the seller takes the sale back to Draft and finalises it again — possible through the API — a second purchase invoice arrives, because nothing looks for the first. If you find two Auto Created From invoices for the same sale number, only one of them belongs in your books.

What this applet will not do

• It will not give you a due date. There is no Due Date field, the column is never written, and Overdue Documents cannot see purchase invoices. See the callout under Fields.
• It will not stop you paying the same bill twice. ENABLE_DUPLICATE_REFERENCE_CHECK turns the Reference box red across the whole tenant, ignores supplier and company, and blocks neither Save nor FINAL.
• It will not enforce a three-way match. No quantity and no price comparison against the order or the receipt happens at knock-off or at FINAL.
• It will not gate FINAL on an approval. Nothing in this applet or in the backend consults a workflow status before finalising; taking the FINAL button away with HIDE_GENDOC_FINAL_BUTTON and withholding the update permission is the only mechanism that works.
• It will not let you undo a FINAL once e-Invoice is enabled. This screen hides VOID from then on (and the server itself refuses to void a self-billed invoice); the correction is a Purchase Debit Note for an invoice billed too high (a Purchase Credit Note raises what you owe, so it fits only one billed too low), or, for a self-billed invoice, a cancellation through the portal inside the LHDN window.
• It will not switch on withholding tax from the settings screen. the SST and WHT enable flags do nothing. The withholding-tax picker on a line is governed by HIDE_WHT_CONFIG_SELECTION, which starts hidden.

Related applets

• Purchase Order (Internal) and Purchase GRN (Internal) — the documents this applet knocks off; the standard GRN does not move stock, the invoice does.
• Purchase Requisition (Internal) and Supplier Delivery Order — earlier steps of the same chain; not knock-off sources in this applet’s current build.
• Purchase Invoice No Stock In (Internal) — the same document with quantity signum 0, for tenants that book stock on GRN Stock In.
• Purchase Invoice Supplier Access (Internal) — supplier-facing view of these invoices.
• Payment Voucher (Internal) — settles several invoices at once; the invoice’s own Payment tab settles one.
• Purchase Return (Internal), Purchase Credit Note (Internal), Purchase Debit Note (Internal) — post-FINAL corrections.
• Supplier Applet — the entity, its AR/AP type and the self-billed flag.
• Chart of Account Applet, Tax Configuration Applet, Cashbook Applet, Organisation Applet — the master data FINAL and Payment depend on.
• Ledger And Journal — where the posted journal is reviewed.
• My E-invoice Portal — submission and tracking of self-billed invoices.

Troubleshooting

Related documentation

• Standard procurement workflow — PR → PO → GRN → Purchase Invoice → Payment
• Direct invoice workflow — invoicing without a GRN
• Invoice-first workflow
• Malaysia e-Invoice guide — self-billed submissions
• Financial Accounting module and Purchasing module

Video overview