Calculated Fields Form stores submissions in WordPress storage, with each entry capturing the field values, the calculated results, and a payment status that flips from Unpaid to Paid when the configured gateway (PayPal, Stripe, RedSys) confirms the transaction. The default entries screen lists rows with limited filtering, so reconciling paid versus unpaid against gateway reports means CSV exports and a spreadsheet.

SleekView reads those entries directly and surfaces payment status, total, form, and email as first-class columns. Pin a saved view for paid entries from this week, one for unpaid older than 24 hours, and one for refunded across all calculators. Filter by total range to find high-value quote requests worth a sales follow-up. Combine form and date filters to see exactly which calculator produced the most paid entries last month.

Inline edits to payment status and notes write through standard WordPress update functions, so any gateway-side reconciliation updates stay consistent and Calculated Fields Form's own hooks fire normally. CSV export of any filtered slice gives finance a clean handoff to accounting without round-tripping through a separate spreadsheet.

Calculated Fields Form is unusual because it sits on the seam between forms and payments. A loan calculator that quotes interest, a tile estimator that takes a deposit, a workshop booking with a fixed fee — each one produces a submission that's also potentially a financial transaction. The plugin handles the calculation and the gateway integration, but its entries screen treats those transactions as flat rows with limited filtering.

For finance teams or sole operators reconciling against PayPal or Stripe reports each week, that's the wrong abstraction. Reconciliation requires payment status as a first-class filter, total as a sortable column, and a refunded view that surfaces the entries needing manual gateway action. Sales teams running quote-style calculators need high-value totals filtered to the top to prioritize outreach.

Support handling refund requests needs entry context and inline notes without flipping into the gateway dashboard. None of this changes how the plugin processes payments. It just turns the submission data the plugin already collects into a working surface that matches how finance, sales, and support actually use it.