How the comparison is built

One ontology, not one format per vendor

Every billable line item in any proposal maps to exactly one category and subcategory in a fixed catalog: administrative fees, statutory taxes, workers compensation, benefits, add-ons, and credits. A vendor calling it a service fee, a co-employment fee, or a professional service fee lands in the same row as one calling it an admin fee. That mapping is what makes two proposals written in two different formats comparable at all.

Three passes over every document

Reading is not a single shot at a PDF.

• Pass one extracts every billable line item it can find and maps each to the ontology.
• Pass two re-reads the same document alongside the pass-one output and hunts specifically for dollar amounts, rates, and percentages that were missed. Findings merge back in.
• Pass three is plain code with no model involved. It sums the extracted items against the totals the document itself states, and flags any critical line item that is missing. A proposal with no administrative fee row is almost certainly mis-read, and it gets called out rather than quietly averaged into a total.

Everything converts to a monthly figure

Vendors quote in incompatible units on purpose and by habit. Normalization puts them on one basis using the client's own census, and the arithmetic is shown rather than asserted.

• Per employee per month multiplies by headcount. Per employee per year does the same and divides by twelve.
• Percent of payroll and rates per hundred dollars of payroll compute against the client's annual payroll.
• Annual amounts divide by twelve. One-time fees amortize across the first twelve months, so an implementation fee is neither hidden nor double-counted.
• A line item that needs a number nobody has supplied yet returns nothing at all rather than a guess, and says which input it is waiting on.

What is deliberately left out of the total

Per-occurrence and usage-dependent fees, such as background checks, garnishments, and off-cycle payroll runs, appear in the ledger where you can see them but are excluded from the total. Their cost depends on behaviour nobody can forecast at quote time, and folding a guess into a headline number produces fake precision on the exact figure a client will repeat back to you. Where an estimate is uncapped, such as unemployment taxes computed against full payroll before wage-base capping, it is labelled uncapped rather than presented as final.

Nothing unverified reaches a client

Numbers extracted from a document are verified against the document text and recomputed in code before they can appear in any client-facing report. Data that has not been reviewed is marked draft and is blocked from client deliverables. Every correction is logged with its root cause, which is what turns a one-off fix into a validation rule instead of a fix that has to be remembered.

Where judgment still belongs to you

Normalization makes proposals comparable. It does not decide which one is right. Plan design, network quality, service model, contract flexibility, and how a vendor has actually behaved on your last five groups are advisory calls, and PEOLens is built to hand you a defensible cost picture quickly so you have the time to make them.