AP Automation Applet

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. It gets your side from three ordinary documents: the Purchase Order, the supplier’s delivery note and your Purchase GRN. A background matcher ties the two sides together by delivery-order number and 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 fully built and routed but its menu entries are commented out, so those screens are reachable only by URL. This page documents the live screens.

Where it fits

Screens and menus

Routed but not on the menu (menu-items.ts has them commented out): payment-statement, payment-statement-line, import-payment-statement, ocr-payment-statement, pmt-stmt-line-report, ocr-company, ocr-branch, ocr-item, inv-item, ocr-report.

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 (search_word — supplier name, supplier code or keyword since issues #10 and #12) 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 posts the file to the e-Invoice OCR upload endpoint and queues the OCR processor. Reprocess sends the selected rows’ identifiers to the reprocess endpoint, which re-queues them through the same OCR processor; 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.

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 (the Export and Withdraw buttons on those tabs are commented out). 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 (EMAIL or PEPPOL). Opening a row shows Main Details with the e-Invoice header read-only and three fields you can change — Payment Status (PENDING / PAID; locked once it is PAID), Finance Remarks and Action Deadline — plus a Save button. The two screens are the same component 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 sends the selected headers’ identifiers to the batch update endpoint. 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 (issue #14).

Opening a row shows four tabs: Main Details (the same editable trio — Payment Status, Finance Remarks, Action Deadline — with everything else 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 an applet-local FieldConfigurationComponent (this applet does not use the shared field-configuration screen) and an applet-local Default Selection. 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, DEFAULT_TIMEZONE. 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

Feature visibility / permissions

Client-side. The code checks one permission, SHOW_CREDIT_NOTE_SUMMARY. bl_applet_client_side_perm_dfn holds zero rows for apAutomationApplet (queried 2026-09-15), so the Client Side Permission screen has nothing to assign and HIDE_CREDIT_NOTE_SUMMARY is all-or-nothing until the code is seeded.

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_* in PmtStmtPermissions); 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 (checked in EInvoiceEmailOcrController). 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 Amazon Textract analysis of the PDF (EInvoiceEmailOcrProcessorService, OcrTextractAnalysisService), with the LHDN unique number and validation date parsed out of the e-Invoice information block. The record is bl_fi_einvoice_email_ocr_doc_hdr; its data_source distinguishes an ordinary supplier e-Invoice from an e-commerce one.

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

The row is bl_b2b_process_tracking_einvoice_hdr; the B2B lines are bl_b2b_process_tracking_ipo_xdo_igrn_hdr rows joined through the matched-history table.

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 three fields a person writes.

    flowchart LR
  subgraph SUP["Supplier's side"]
    MAIL["E-mailed PDF<br/>(connected mailbox task)"] --> OCR["EINVOICE_EMAIL_OCR_PROCESSOR<br/>Amazon Textract →<br/>bl_fi_einvoice_email_ocr_doc_hdr"]
    UP["Uploaded PDF<br/>(OCR E-invoice → Create)"] --> OCR
    PPL["Received over Peppol<br/>bl_ppl_from_peppol_generic_doc_hdr"]
  end
  OCR --> Q1["XTN_EINVOICE_MATCHING_QUEUE_PROCESSOR<br/>last hour's new or updated records →<br/>bl_b2b_xtn_einvoice_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["IPO_XDO_IGRN_QUEUE_PROCESSOR<br/>last hour's updated documents →<br/>bl_b2b_ipo_xdo_igrn_queue"]
  GRN --> Q2
  Q2 --> B2B["IPO_XDO_IGRN_PROCESSOR →<br/>bl_b2b_process_tracking_ipo_xdo_igrn_hdr<br/>(B2B Summary), PO linked by Client Doc 2"]
  PO -.-> B2B
  Q1 --> M["XTN_EINVOICE_MATCHING_PROCESSOR →<br/>bl_b2b_process_tracking_einvoice_hdr<br/>(E-invoice Summary)"]
  B2B --> M
  M --> R["B2B vs E-invoice Summary<br/>document M/UM · value M/UM · amount difference"]
  R --> REP["XtnEinvoiceMatchingReportProcessor<br/>Excel report e-mailed to the<br/>Consolidated Arap group's logins"]
  

Your side, step by step. IpoXdoIgrnQueueProcessor (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. IpoXdoIgrnProcessorService 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-order number equals the GRN’s Client Doc 3, or creates a new one. 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. XtnEinvoiceMatchingQueueProcessor 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. XtnEinvoiceMatchingProcessorService 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 setting match_source. For a Peppol document that is the end of processing. 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; those documents appear in the Credit Note Summary and E-invoice Summary but are never matched or valued.
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) equals the number, upper-cased and trimmed, retrying with leading zeros stripped from either side. 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_status becomes M. The matched rows’ GRN amounts (including tax) are summed.
4. amount_difference = e-Invoice amount − summed GRN amount. value_matching_status 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’s last_processed_datetime is stamped and it stays in the queue — the next run tries again, which is how a GRN keyed after the e-Invoice arrived is picked up.

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. XtnEinvoiceMatchingReportProcessorService 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 through Amazon SES 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 is triggered by the …/xtn-einvoice-matching-report-processor endpoint or a scheduled job. A group with no linked logins is skipped with a warning.

What a person writes. Payment Status, Finance Remarks and Action Deadline on the summary screens, singly or — for payment status — in bulk. These are columns on the tracking row and nothing else reads them.

Posting proof. Server document type: none — no ServerDocTypes entry, no data-consistency object of the generic-document family; ProcessTrackingEinvoiceDataConsistencyObject validates only that a GUID is present on creation and that referenced OCR and Peppol headers exist. Amount signum / quantity signum: not applicable. Dr / Cr equation: none — no handler in JournalPostingTypeHandler and no journal call anywhere in the pmtStmt package. Stock processor: none. VOID: none — rows are updated in place by the processors, and the OCR record is re-read by Reprocess.

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.
• 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