WooCommerce PDF Invoice Pro (and the broader family of WooCommerce PDF Invoices & Packing Slips plugins) writes invoice metadata to postmeta on each shop_order: _wcpdf_invoice_number, _wcpdf_invoice_date, and a sent flag often stored alongside the order's existing email-sent meta. The actual PDF is generated on demand, not stored.

The default Orders screen shows nothing of this. Accounting and AR teams have no way to confirm at the list level whether a particular order has an invoice number assigned, whether the PDF was generated, or whether the customer was emailed. Auditing a month's invoice coverage means clicking into every order or running raw SQL on postmeta.

SleekView reads the meta directly and exposes invoice number, invoice date, and email-sent state as proper columns. A saved view scoped to orders missing an invoice number flags coverage gaps. Bulk-trigger regeneration through the plugin's own action hook (where supported) and the original PDF formatter still runs.

Invoice coverage is one of the silent failure modes of a busy WooCommerce store. An order ships, the customer pays, but the invoice never generates because the plugin failed to trigger on that specific status transition, or the customer email never went out because the SMTP relay hiccuped. Two months later, accounting hits the close and notices fifty orders missing invoice numbers.

The data has always been there in postmeta on each shop_order (invoice number, generation date, email-sent flag), but the default Orders screen shows none of it. SleekView turns the postmeta into proper columns, so coverage gaps surface in seconds instead of months. A saved view scoped to orders missing _wcpdf_invoice_number flags the gap continuously.

A monthly close view groups by invoice date and sums totals for the accounting reconciliation. A support team can confirm an invoice was emailed in one row instead of clicking into the order and the email log. The plugin already captures the data; SleekView just makes the audit operational.