Every compliance vendor shows a logo wall of integrations. Most of those logos mean something narrower than a buyer assumes. Here is what ours actually means, and what we say instead.
Somewhere in the second call, a buyer asks whether we integrate with their timekeeping system. It is the right question and I have come to dread it, because the honest answer takes ninety seconds and the dishonest one takes four words.
The four-word answer is "yes, we support that." Every vendor in this category can say it about nearly every system, and most of them do, because a logo wall is cheap to build and nobody audits it. Behind those logos, "integration" covers a range that runs from a maintained production API connector to a documented CSV format to an engineer who once wrote a script for one customer.
So here is the ninety-second version.
The systems we have production connectors against today are BusyBusy, Gusto, and DocuSign. That is the proven base. Not a marketing selection — the actual list.
For anything else — ADP Workforce Now, Paylocity, UKG, ExakTime, Samsara, Motive, Geotab, QuickBooks, or whatever combination your operation grew into — we build the connector for your stack: by API where one exists, by export, SFTP, or structured manual entry where one doesn't. It is scoped and priced in the records diagnostic, before anyone signs anything, so the number is a number, not an estimate that moves during implementation.
Those named systems are what we build on. They are not a catalog of connectors that already exist, and I would rather be boring about that up front than have it discovered in week three.
Two reasons, and the second one is the real one.
The first is straightforward. Implementation timelines in this category die on integration assumptions. A buyer who believes a connector exists plans a four-week deployment; the same buyer, told accurately that the connector is a two-week build, plans a six-week deployment and hits it. Same work, same cost, completely different experience of the vendor — and the difference is entirely in what was said in the second call.
The second reason is that in this particular product category, a vendor's willingness to be precise about a small, checkable claim is the best available proxy for its behavior on the large, uncheckable ones.
Think about what we are selling. It is a record intended to be produced in discovery and relied on by counsel. Every substantive claim we make about statutory mechanisms — what §2699(g)(2) enumerates, what a cap does and does not reach, what no court has yet held — is a claim the buyer cannot easily verify at the moment it is made. Most buyers do not have the statute open. Most buyers are hearing this vocabulary from three vendors in the same month, all of them fluent, all of them confident.
The integration question is different. It is small, concrete, and falsifiable inside of one implementation. A vendor who shades it is telling you exactly what it does with the questions you cannot check.
I am aware that this argument is self-serving. I make it anyway, because I would apply it to us, and because it is the reasoning I would want a buyer to use when we are the ones being evaluated.
Since I am claiming precision, here is the substance of it.
Where a real API exists, the work is authentication, mapping the customer's field conventions to ours, handling pagination and rate limits, and reconciling the first month against the source system until the numbers match exactly. Two weeks is typical. The reconciliation is the part that takes the time and the part that matters — a connector that pulls 98 percent of punches is not a connector, it is a source of future arguments about whose number is right.
Where there is an export but no API, we take the scheduled file. This is less elegant and works fine. The engineering question is not the parsing; it is the failure mode. What happens when the file does not arrive on Tuesday, and who finds out? An unmonitored export is worse than no integration, because it produces a record with a hole in it that nobody notices until the hole matters.
Where there is neither — and there is more of this in construction than anyone likes to admit, because the timekeeping is a foreman with a clipboard — we do structured manual entry, and we are direct about what that means: a person is doing data entry, that costs money every month, and the accuracy ceiling is set by the source. If the underlying practice is a lead writing "7:00 to 3:30" in half-hour blocks, no integration architecture repairs that. The block entry is itself a problem, and it is the one to fix first.
One constraint that is not negotiable, because it goes to whether the record is worth anything: attestation prompts have to fire on unrounded punch times. Where the timekeeping underneath rounds, deployment turns the rounding off. Where unrounded punches cannot be supplied at all, we say so, instead of running prompts against numbers that have already erased what the prompt exists to find.
We do not replace your stack. MicroForensics is an orchestration layer above the timekeeping, payroll, and HRIS you already run, and the crews keep clocking exactly the way they do today. A compliance deployment that also asks four hundred field employees to learn a new time clock is two projects, one of which will fail and take the other with it.
We also do not read from systems we do not need. The scope is the data the compliance record actually requires, and the diagnostic states which fields those are before we connect anything.
Not "do you integrate with X." Ask this instead:
Name a customer running that connector in production today, and tell me when it was built.
The answers sort quickly. Sometimes it is a live connector with a date. Sometimes it is a documented file format, which is a fine answer if it is given as that answer. And sometimes there is a pause, followed by a sentence about the roadmap.
You are not looking for a particular answer. You are looking at how the vendor behaves when a claim can be checked — because that is the same vendor you will be relying on for the claims that cannot.
Bring the list of systems and who administers each, and I will scope the stack on a discovery call: what connects by API, what by export, what needs a person, and what each costs. If your existing tooling already produces the record, I will say so, and there will be nothing here for us to build.