AP Automation Applet

Check your suppliers’ e-invoices against what you ordered and received, and work the exceptions. Nothing here posts or creates a supplier balance, and nothing matches until the matching jobs are scheduled and your GRNs carry the supplier’s delivery-order number in Client Doc 3; the External Delivery Order field is never read.

Your job, and the screen for it

Overview

The AP Automation Applet is an accounts-payable reconciliation console, not a document applet. It answers one question for a finance team that buys from many suppliers: of the e-Invoices our suppliers have issued to us, which ones line up with what we ordered, what they delivered and what we received — and which do not?

It gets the supplier’s side from two feeds: e-Invoice PDFs — e-mailed to a mailbox connected to the tenant, or uploaded by hand — which are read by OCR into a structured record; and e-Invoices received over Peppol, which it lists but never matches. It gets your side from three ordinary documents: the Purchase Order, the supplier’s delivery note and your Purchase GRN — and of those three only the GRN is required. A background matcher ties the two sides together by the supplier’s delivery-order number as typed on your GRN and the supplier name, compares the e-Invoice amount with the receipt amount, and records a document matching status, a value matching status and the amount difference. Finance then works the exceptions from the B2B vs E-invoice Summary, records a payment status and remarks, and — through the AP Automation Supplier Access twin — lets each supplier see and annotate their own unmatched rows.

The window title is AP Automation Applet. Four of its screens are live; a payment-statement family (OCR of supplier payment statements, statement import, statement lines and a line report) is not on the menu in the current build. This page documents the live screens.

Two supplier invoices in one week at GadgetSphere Distribution

GadgetSphere Distribution (GSD) buys wireless audio from an authorised distributor and cables and cases from an accessory wholesaler. Both bills arrive in the same week, and the applet treats them very differently from what a clerk might expect.

The distributor’s e-invoice arrives as a PDF in the connected mailbox: invoice INV-88213, RM 18,550.00 including tax, quoting delivery order DO-55012. Your receiving clerk keyed the GRN on Tuesday with DO55012 in Client Doc 3. On the next matching run the OCR record is already there; the matcher finds no exact DO-55012, retries with the dash removed, finds the GRN’s row under a supplier name close enough to the e-invoice’s, and sums that GRN’s amount including tax: RM 18,550.00. The row on B2B vs E-invoice Summary reads Document Matching M, Value Matching M, Amount Difference 0.00.

The wholesaler’s paper invoice is scanned and uploaded on OCR E-invoice → Create. The reader does not check that a PDF is an e-invoice, so the scan is read exactly like one; its LHDN unique no simply stays empty. The invoice is RM 2,384.00 against a GRN of RM 2,348.00, so it lands at Document M, Value UM, Amount Difference 36.00. It is retried on every run for 30 days. After that it drops out of the queue and, because its document match is already M, nothing puts it back: a GRN corrected in week five never changes these figures.

What the clerk still does, for both. Book each bill in Purchase Invoice (Internal), created from the GRN, with the supplier’s invoice number as its Reference; settle it with a Payment Voucher; then come back here and set Payment Status to PAID. For the wholesaler, settle the RM 36.00 with them first and write the outcome in Finance Remarks. The applet tells you which bill is safe to book; it books neither.

Had the distributor sent the same invoice over Peppol, it would appear on B2B vs E-invoice Summary with Source PEPPOL and no matching status at all, and not on E-invoice Summary. That comparison is yours to make by eye. Had the wholesaler numbered its invoices SCN-0412, the letters CN inside the number would file it as a credit note, and it would never be matched.

Where it fits

Relationships with the rest of purchasing

Before it can work. Three things must exist, and none of them is on these screens: GRNs keyed with the supplier’s delivery-order number in Client Doc 3; Scheduler entries for the matching jobs (see Before you can use it); and a way for PDFs to arrive, either the connected mailbox or someone uploading them. Miss the first and every invoice sits at UM; miss the second and the summaries stay empty however many PDFs arrive.

What becomes possible. A checked list before anyone keys a purchase invoice: the bills whose amount equals what you received, and the short list that needs a phone call. Once a row reads M and M, you can create the purchase invoice from that GRN knowing the supplier billed what arrived. It also gives each supplier a window on its own rows through the supplier-access twin and the e-mailed matching report, so the supplier writes the explanation instead of you chasing it.

The matching it is often confused with. My E-Invoice Admin also pairs supplier e-invoices with your documents, but after the fact and for a different question: it pairs an e-invoice received over Peppol with a purchase document you have already finalised, so you can show that every bill you booked has the supplier’s validated e-invoice. This applet works before the purchase invoice exists, against your GRNs, and asks whether the supplier billed what you received. Use this one when you are deciding what to book and pay; use the admin one when you have to prove the e-invoice trail. The PDFs read here are not handed to the admin pairing, and Peppol invoices are matched only there.

What a mistake here breaks elsewhere. Nothing in the ledger, because nothing here posts. Three things do reach beyond this screen. Payment Status is visible to the supplier: set PAID before the payment voucher is out and the supplier reads that it has been paid. Making Client Doc 3 editable is a setting of the Purchase GRN applet, so it opens that box on the GRN screen for everyone who keys GRNs there, whatever the GRN is for. A GRN keyed with another GRN’s Client Doc 3 blocks the supplier’s e-invoice from matching at all until one of them is corrected.

What it is used alongside in practice. The Purchase GRN receiving habit, which feeds it; the Purchase Invoice created from the matched GRN, which it clears the way for; the Payment Voucher, after which Payment Status here is worth setting; and the Scheduler, without which none of it moves.

Screens and menus

OCR E-invoice

The listing shows Supplier Name, E-invoice No, Transaction Date, Transaction Amount, Purchase Order No, Delivery Order No, Validation Date, LHDN unique no and Updated Date, with a general search (supplier name, supplier code or keyword) and an advanced search on supplier name, e-Invoice number, delivery-order number and e-Invoice date range. Rows are multi-select.

Create opens Upload E-invoice: a drag-and-drop zone that accepts one .pdf at a time and an ADD button, which uploads the file and queues it for OCR. Reprocess re-queues the selected rows through the same OCR reader; the toast reports Successfully processed N item(s) and M item(s) not found.

Opening a row shows View OCR E-Invoice with two tabs — Document Details (every field OCR extracted, read-only, including a Confidence Lvl) and Lines (Item Code, Item Name, Item Classification, Item Description, Qty, Unit Price Txn (Incl of Tax), Amount Txn, Amount Net, Discount Amount, Discount Rate, Amount Tax, Tax Rate). Nothing on either tab can be edited; a misread e-Invoice is corrected by reprocessing or re-uploading, not by typing.

How the reader decides what a PDF is. It does not test that the PDF is an e-invoice: a scanned paper invoice is read the same way and keeps an empty LHDN unique no, and nothing downstream rejects it for that. It files the record as a credit note (02) when it finds a credit-note number, or when the invoice number contains the letters CN anywhere; everything else is an invoice (01). A supplier whose numbering happens to contain those two letters has every invoice filed as a credit note, listed on Credit Note Summary and never matched. Confidence Lvl is the average of the reader’s confidence across the fields it extracted, so a low figure says something was hard to read, not which field; check the delivery-order number and the total first, because those two decide the match.

B2B Summary

Columns: Supplier Name, Supplier Code, Purchase Order No, Delivery Order No, Delivery Order Date, DO No. (From GRN), GRN No, GRN Date, GRN Amount, E-invoice No, E-invoice Date, E-invoice Amount. Opening a row shows three read-only tabs — Purchase Order, Delivery Order, GRN — each listing the linked document’s header. Advanced search is by supplier name only.

E-invoice Summary and Credit Note Summary

Columns: Supplier Name, E-invoice No, E-invoice Date, E-invoice Amount, Purchase Order No, Delivery Order No, Validation Datetime, LHDN unique no, Source. Source reads EMAIL here in practice: a Peppol reception carries no e-invoice code, so these two type-filtered screens never list it. Opening a row shows Main Details with the e-Invoice header read-only and two fields you can change — Payment Status (PENDING / PAID; locked once it is PAID) and Finance Remarks — plus a Save button. Action Deadline is shown beside them read-only: it is the supplier’s date, set in the supplier-access applet, and your Save does not write it. The two screens are the same view with the e-Invoice type filter set to 01 and 02 respectively.

B2B vs E-invoice Summary

The working screen. Each row is an e-Invoice header with the B2B rows it matched as lines. Columns prefixed B2B come from the matched delivery-note / GRN rows (supplier, PO, DO, DO No. (From GRN), GRN No, GRN Date, GRN Amount, E-invoice No); the rest come from the e-Invoice header — Supplier Name, E-invoice No, E-invoice Date, E-invoice Amount, Amount Difference, Purchase Order No, Delivery Order No, Document Matching (M when the header has at least one matched line, else UM), Value Matching, Supplier Remarks, Action Deadline, Finance Remarks, Payment Status.

Above the grid: Select All Displayed, Clear Selection, a Payment Status picker (PAID / PENDING) and APPROVE, which updates the selected rows in one go. Rows already PAID are skipped and counted in the toast. Advanced search: supplier name (a B2B and an e-Invoice supplier name separately), GRN date range and e-Invoice date range; the criteria switch between header and line supplier-name columns depending on which dates are set.

Opening a row shows four tabs: Main Details (the same two editable fields — Payment Status and Finance Remarks — with everything else, the supplier’s Action Deadline included, read-only) and read-only Purchase Order, Delivery Order and GRN tabs for the matched documents.

Configuration

Before you can use it

Applet settings

Settings live in the applet’s own Field Settings and Default Selection screens. Administrators with access to the Settings menu change them; the values are stored as the applet’s master settings.

Field Settings — one control:

Default Selection — DEFAULT_BRANCH, DEFAULT_LOCATION, DEFAULT_COMPANY, The default time zone. Declared, rendered (a branch picker that also fills company and the branch’s main location) and saved — but no listing or search screen in this applet reads them; the only consumer is the Personalization mirror of the same four keys. Setting them changes nothing visible today.

Document behaviour settings

Not applicable — the applet creates no generic document and has no posting, printable or workflow settings.

Settings in other applets, and configuration with no screen

Who can change what

Client-side. The applet checks one permission, SHOW_CREDIT_NOTE_SUMMARY — but no client-side permission is registered for this applet, so the Client Side Permission screen has nothing to assign and HIDE_CREDIT_NOTE_SUMMARY is all-or-nothing until it is added.

Server-side. Reading the summaries needs the read permission on process-tracking e-Invoice and process-tracking IPO/XDO/IGRN records (API_TNT_DM_PROCESS_TRACKING_EINVOICE_*, API_TNT_DM_PROCESS_TRACKING_IPO_XDO_IGRN_*); saving remarks or payment status needs the corresponding update permission. Uploading or reprocessing an e-Invoice PDF needs API_TNT_DM_EINVOICE_EMAIL_OCR_DOC_CREATE. The Permission Wizard, Set, User, Team and Role screens are the shared ones.

Fields

OCR E-invoice → Document Details (read-only)

Every field is populated by OCR analysis of the PDF, with the LHDN unique number and validation date parsed out of the e-Invoice information block. The record also notes whether it is an ordinary supplier e-Invoice or an e-commerce one.

E-invoice Summary / Credit Note Summary / B2B vs E-invoice Summary → Main Details

Lifecycle and effects

This applet owns no generic document, so there is no DRAFT / FINAL / VOID. What it has is a pipeline of four scheduled processors that populate its tables, and two fields your finance team writes.

    flowchart LR
  subgraph SUP["Supplier's side"]
    MAIL["E-mailed PDF<br/>(connected mailbox task)"] --> OCR["OCR reader →<br/>OCR e-Invoice record"]
    UP["Uploaded PDF<br/>(OCR E-invoice → Create)"] --> OCR
    PPL["Received over Peppol"]
  end
  OCR --> Q1["Matching queue run<br/>last hour's new or updated records →<br/>matching queue"]
  PPL --> Q1
  subgraph YOU["Your side"]
    PO["Purchase Order · FINAL"]
    XDO["Supplier delivery note<br/>SUPPLIER_OUTBOUND_DELIVERY_NOTE"]
    GRN["Purchase GRN<br/>Client Doc 3 = supplier's DO no"]
  end
  XDO --> Q2["B2B queue run<br/>last hour's updated documents →<br/>B2B queue"]
  GRN --> Q2
  Q2 --> B2B["B2B processor →<br/>B2B Summary row,<br/>PO linked by Client Doc 2"]
  PO -.-> B2B
  Q1 --> M["Matching processor →<br/>E-invoice Summary row"]
  B2B --> M
  M --> R["B2B vs E-invoice Summary<br/>document M/UM · value M/UM · amount difference"]
  R --> REP["Report run<br/>Excel report e-mailed to the<br/>Consolidated Arap group's logins"]
  

Your side, step by step. The B2B queue run (or its monthly variant, which uses the transaction date instead) scans generic documents of type SUPPLIER_OUTBOUND_DELIVERY_NOTE and INTERNAL_PURCHASE_GOODS_RECEIVED_NOTE updated in the window (the last hour by default), plus deleted ones, and writes or refreshes one queue row per document with its five client document numbers, supplier entity and amount. The B2B processor then folds each queue row into a B2B Summary row: a delivery note creates or updates the row keyed by its own header; a GRN updates the row for its header, or — failing that — the row whose delivery-note number equals the GRN’s Client Doc 3, or creates a new row of its own. So a GRN needs no delivery note to appear here or to be matched. On creation the supplier’s code and name are copied from the entity, and the PO is linked when the document’s Client Doc 2 equals exactly one FINAL purchase order’s Client Doc 1 for that supplier; zero or several matches are logged and the row proceeds without a PO. Deleted documents mark the queue row inactive. The queue row is deleted once processed.

Supplier’s side, step by step. The matching queue run scans OCR records and Peppol documents updated in the window and writes one matching-queue row per document, de-duplicated by supplier name and document number. The matching processor takes each queue row and creates or updates the E-invoice Summary row (looking first by OCR header, then by supplier name with similarity > 0.5 and the same document number), copying every header field and recording the source. For a Peppol document that is the end of processing: its queue row is deleted, it is never matched, and because its row carries no e-invoice code it is listed only on B2B vs E-invoice Summary. For an OCR document it then tries to match:

1. Only e-Invoice code 01 (invoice) is matched. Any other type — credit note 02, debit note 03, refund note 04 — has its queue row deleted immediately and is never matched or valued. A credit note still appears on the Credit Note Summary; a debit note or refund note appears on neither summary, because one lists only type 01 and the other only 02.
2. The e-Invoice’s Delivery Order No is split on commas. For each number the processor looks for a B2B row whose supplier name is similar (> 0.5) and whose DO No. (From GRN) — the GRN’s Client Doc 3 — equals the number, upper-cased and trimmed; it then retries with a DO or DO- prefix taken off or added, with leading zeros stripped from either side, and with dashes removed. The delivery note’s own number is never compared. If the name finds nothing, each alias in the tenant’s alias configuration is tried. More than one candidate row throws and the queue row is left for the next run.
3. Each matched B2B row is stamped with the e-Invoice’s number, amount, date and validation time; Document Matching becomes M. The matched rows’ GRN amounts (including tax) are summed.
4. Amount Difference = e-Invoice amount − summed GRN amount. Value Matching is M only if the document status is M and the difference is exactly zero.
5. On an exact value match a row is written to the matched-history table per B2B row and the queue row is deleted. On any other outcome the queue row is stamped with the attempt time and stays in the queue — the next run tries again, which is how a GRN keyed after the e-Invoice arrived is picked up. The retry has limits. A queue row older than 30 days is dropped at the start of a run; one whose document match is still UM (or never set) is re-queued straight away, for e-Invoices dated within the last six months, but one at document M and value UM is not, so its Amount Difference is frozen from then on.

No e-Invoice without a delivery-order number can ever match; a supplier who invoices against the PO number only will sit at UM indefinitely.

The report. The report run builds, per Consolidated Arap group and date window, an Excel file E-Invoice vs B2B Matching Report.xlsx from the B2B vs E-invoice query and e-mails it to the main e-mail of every login linked to that group, with a fixed body asking the supplier to update remarks and action deadlines in the supplier-access applet. It runs from a schedule or on demand by support. A group with no linked logins is skipped with a warning.

What a person writes. Payment Status and Finance Remarks on the summary screens, singly or — for payment status — in bulk. Supplier Remarks and Action Deadline are written by the supplier in the supplier-access applet and are read-only here. Nothing else reads any of the four.

Posting proof. Server document type: none — this is not a generic document. Amount signum / quantity signum: not applicable. Dr / Cr equation: none — nothing here posts a journal. Stock processor: none. VOID: none — rows are updated in place by the processors, and the OCR record is re-read by Reprocess.

What this applet will not do today

Everything above describes code that exists and works. None of it is running anywhere we can see, and one link in the chain has no supply at all. Four different facts get confused with each other, so here are all four, separately.

Shipped. Yes. Both applets and the processing behind them are part of the shared platform, not gated to any tenant.

Registered. Yes. Both applets are active in the applet registry and every processor is registered. They are product — built for one customer first, and meant for any tenant that can get supplier e-Invoices into BigLedger and key GRNs with the supplier’s delivery-order number.

Scheduled. Not by anything the platform does for you. The four processors that do all the work (XTN_EINVOICE_MATCHING_QUEUE_PROCESSOR, XTN_EINVOICE_MATCHING_PROCESSOR, IPO_XDO_IGRN_QUEUE_PROCESSOR, IPO_XDO_IGRN_PROCESSOR), the monthly variant, the report processor and the three payment-statement processors are none of them scheduled by default, so each needs a Scheduler entry created before anything on these screens moves on its own. Nothing sweeps them up: unlike the OCR reader, which is queued on demand when a PDF is uploaded or arrives by e-mail, these four fire only from a schedule or when support triggers them. A tenant that switches the applet on and waits will wait for ever. Ask your BigLedger contact to add the job rows — do not read the screens as evidence that anything is running.

Running. Not that we can see. The OCR reader has been used; the matching that fills the E-invoice Summary and the B2B Summary — the rows every other screen on this page is about — has not run anywhere.

What you need, and what you do not. You do not need supplier delivery notes as documents. That type (SUPPLIER_OUTBOUND_DELIVERY_NOTE) can only arrive through the API, from an integration built for you, but the matcher does not depend on it: a GRN creates its own B2B Summary row, and the e-Invoice is matched against the GRN’s Client Doc 3. A delivery note, where an integration supplies one, only fills the row’s Delivery Order tab.

Peppol invoices are listed, not matched. A supplier who moves from e-mailed PDFs to Peppol drops out of the matching here, with no message; pair those bills on My E-Invoice Admin instead, or compare them with the GRN by eye.

What that means for you, concretely. The work to make this applet useful is a scheduling request plus a receiving habit: ask your BigLedger contact to schedule the four jobs, and have whoever keys GRNs put the supplier’s delivery-order number in Client Doc 3 — not in External Delivery Order. On the GRN screen Client Doc 3 is read-only until an administrator turns on EDITABLE_CLIENT_DOC_3 (and hidden while HIDE_CLIENT_DOC_3 is on), so that setting comes first. Then check the supplier names on their e-Invoices against your supplier records, and ask for an alias where they differ. A GRN keyed without the number has nothing to match on, and the queue only looks back over recently updated documents. Neither half is something the applet does for you.

What success looks like

Thirty seconds, once a week, on one supplier you received goods from:

1. Open B2B vs E-invoice Summary and search that supplier. Each of last week’s invoices shows Document Matching M, Value Matching M and an Amount Difference of 0.00, and its GRN tab names the GRN you received against.
2. In Purchase Invoice (Internal), search the supplier’s invoice number in Reference: exactly one invoice, FINAL, created from that GRN, with a total equal to the E-invoice Amount here.
3. Payment Status here reads PAID only for the bills a Payment Voucher has settled.

If step 1 shows nothing newer than a day or two, the matching is not running on your tenant (see What this applet will not do today). If step 2 finds a purchase invoice whose row here still reads UM, the bill was booked before the difference was settled: that is the row to raise with the supplier today.

Related applets

• AP Automation Supplier Access — the supplier’s window on the same rows; where Supplier Remarks come from.
• Supplier — the entity whose name is matched, and the Consolidated Arap groups that decide who receives the report.
• Purchase Order (Internal) — linked into a B2B row by its Client Doc 1.
• Purchase GRN (Internal) — the document whose Client Doc 3 is the matching key and whose amount is the value compared.
• Purchase Invoice (Internal) — where the supplier’s bill is actually booked; this applet neither creates nor reads it.
• MyPeppol Admin — the From Peppol AP receptions that form the second feed, listed here but matched only on My E-Invoice Admin.
• My E-Invoice Admin — the other supplier-invoice pairing: Peppol e-invoices against purchase documents you have already finalised. Choose it to prove the e-invoice trail; choose this applet to decide what to book.
• Payment Voucher — where the bill is actually paid; set Payment Status here only after it has gone out, because the supplier can see it.
• MY E-Invoice Portal — the tenant’s own outgoing and self-billed e-Invoices; a different subsystem from the incoming OCR records read here.

Troubleshooting

Related documentation

• Purchasing Module — where this applet sits, and why it is not a matching engine for purchase invoices
• E-Invoice Module — the incoming and outgoing e-Invoice subsystems
• Incoming supplier e-Invoices — the guide to receiving supplier e-Invoices