PC Financials
Book intro →
PC Financials
Book intro →
The plumbing around the GL — close calendars, expense policy, approval routing, vendor onboarding — written down once, then maintained by the firm.
PC Financials retires the operational debt that makes a close slip — documenting the close calendar, AR/AP approval routing, expense policy, and vendor/1099 hygiene. A two-week diagnostic, written recommendations, then implementation across the stack.
The pattern that signals §5 is usually some version of “the close keeps slipping and I can’t tell why.” The books look reasonable. The bookkeeper is competent. The tools are in place. And still — most months, the close lands on day 10 instead of day 7, and once a quarter it lands on day 14. Pulled apart, the slippage isn’t bookkeeping; it’s process. The AP queue piles up because approvals route through a person who’s traveling. Expense reports trickle in over the first ten business days of the month. Vendor data is incomplete, so the W-9 chase blocks the 1099 work in January. None of these are bookkeeping problems. They’re operational debt that the bookkeeper absorbs every month because there’s no documented owner.
§5 is the engagement to retire that debt.
Every engagement starts the same way: a two-week diagnostic. We sit with the finance team and the operators upstream of finance, walk every recurring workflow that touches money — billing, collections, payables, payroll, expense, vendor management, intercompany, allocations, close — and document what’s happening today. Not what the SOP says is happening. What’s actually happening.
The output of the two weeks is a written report. Three sections: what’s working (and shouldn’t change), what’s broken (with the cost and the root cause), and what we’d recommend doing about it. Recommendations are scoped at three levels — quick wins implementable in a week, structural changes implementable in 4–8 weeks, and longer-horizon things to revisit later. We tell the operator which ones are worth doing and which ones aren’t, with the reasoning.
The diagnostic is the deliverable on its own. Operators sometimes take the report, implement the recommendations in-house, and don’t need us for the implementation. That’s a fine outcome. We bill for the diagnostic, deliver the report, and the engagement ends. More often, the recommendations are enough work that the operator asks us to implement them, which is the rest of the engagement.
The single most leveraged artifact this engagement produces is the close calendar. Day-by-day, what gets done, who does it, what the dependency chain looks like, and what the SLA is for each step. Most shops we take over have a close calendar that exists implicitly in one person’s head; when that person is out, the close slides. Written down with named owners, the calendar is a managerial instrument — the controller can see on day 4 that AR confirmation is at risk and intervene before it cascades.
The calendar isn’t a Gantt chart. It’s a one-page document with a table and a few notes, lives in Notion, gets updated when the cadence changes. The discipline of keeping it current is the engagement’s real value; the document itself is short and looks ordinary.
The standard build is invoices into Bill.com or Stampli, three-tier approval routing (coder, reviewer, approver) with limits, integration with Ramp or Brex for card spend, automatic GL coding from rules with a fallback to the categorization agent (§1), payment release once approved. The build takes about three weeks for a typical client.
The detail that matters is routing fallback. Approvals fail because the named approver is on vacation, on a flight, or just slow. The routing has to know what to do when that happens — escalate to a backup after a defined window, send a reminder on a defined cadence, never let a payable sit unrouted longer than a defined limit. The shops where this is set up properly are the ones where AP doesn’t become an end-of-month scramble.
Most engagements come in with one of two failure modes on expense: a policy that’s three pages long, nobody reads, and isn’t enforced; or no policy at all, with a corporate card program that’s grown by accretion. The fix is the same in both cases — a one-page policy that reflects what the operator actually wants to enforce, a card program implemented in Ramp or Brex with the rules baked into the platform so enforcement isn’t manual, and a monthly reconciliation cycle that closes by day 5.
We write the policy. The operator approves it. We implement the rules in the card platform. After that, expense work shrinks to a fraction of what it was — most categorization is automatic, most reconciliation is automatic, the exceptions surface to the controller in a queue rather than as a fire drill on day 11.
The other quiet failure mode is vendor data. Most companies’ QuickBooks files have vendors with missing W-9s, missing addresses, missing TINs, and 90% of those vendors are 1099-reportable. January every year, a junior accountant spends two weeks chasing the missing data, sometimes missing the filing deadline.
The fix is upstream: an onboarding flow that collects the W-9, the address, the TIN, the payment method, and the GL coding default before the first invoice is paid. Implemented once, the 1099 cycle in January becomes a half-day export instead of a two-week chase. We build the onboarding flow as part of the engagement.
Process and tooling can’t separate. A close calendar that depends on a manual Shopify export every Monday is half a process problem and half a tooling problem. Fixing only the process — assigning the export to a named owner — is worse than nothing, because the named owner will eventually be on PTO and the close will slip anyway. Fixing only the tooling — automating the Shopify export — without naming the owner means there’s nobody to look at it when the integration breaks.
Run together, §5 documents the workflow and §2 builds the integration. The engagement is faster because the diagnostic doesn’t happen twice, and the deliverables compose — a documented calendar with the right level of automation underneath each step. Most engagements that arrive as “we need a §5” turn into both lines after the diagnostic.
ERP implementations — NetSuite, Sage Intacct, the larger Microsoft Dynamics products — are not what this engagement does. The diagnostic and the small-scale process work make sense for businesses operating below the ERP cutover threshold. Above it, the right partner is an implementation specialist, and we refer out. We’ll happily participate in selection and in the finance-team-side work during a migration, but we don’t lead the implementation itself.
If we're a fit, you get a written scope within the week. If not, we'll point you somewhere that is.