WooCommerce Sage Accounting connectors push orders into Sage as invoices and write the resulting invoice ID, customer ID, and sync state back to each order. The order list never gets a column for any of that, so the only path to inspect state is opening orders one at a time and reading the Sage meta box. That is a per-order click pattern that does not survive month-end backlog.

SleekView reads wc_orders (or shop_order on legacy) and exposes the connector's meta keys, typically _sage_invoice_id, _sage_customer_id, _sage_sync_status, and _sage_sync_error, as real columns. Sort by sync state, filter by date range and currency, and group by error reason so the queue becomes a list you can triage in one session.

Inline edits route through the connector's CRUD layer where supported, so retrying a sync still calls the Sage API client and order-status hooks still fire. Bulk-retry every failed sync from a date range using the same logic the per-order retry button uses, then export the cleared queue for the accountant.

Sage Accounting is a credible target for WooCommerce sync, especially in UK and Irish stores where VAT period reporting matters. The connector does the API work and writes the invoice and customer IDs back to each order. The default Orders screen still does not expose any of that.

Finance teams end up exporting from Sage and reconciling against WooCommerce by hand at the end of every VAT period. That gap is exactly what SleekView closes. The connector still owns the API client and the credentials; SleekView turns the meta it already writes into a real list-table workspace with the columns and filters reconciliation actually needs.

Filter by sync state, group by error reason, bulk-retry the failures, export the cleared queue for the VAT return. Same database, same hooks, dramatically less hunting through orders to find which ones still need an invoice in Sage.