Explore intelligent solutions for payroll data operations
What implementation and onboarding managers at nearly 200 B2B software companies spend most of their time on, and why so much of it goes beyond simply importing customer data.
The report in one sentence
Implementation is a data project wearing a software project’s name.
Across a year of conversations with implementation managers, onboarding leads, and professional-services directors, one pattern held almost without exception: the costly part of onboarding a customer isn’t configuring the product. It’s getting the customer’s data into a format the product will accept – and the most expensive stretch of that sits before anyone clicks the import button.
This report is not a survey. It’s a synthesis of working conversations – discovery calls, technical deep-dives, proofs of concept, and delivery reviews – in which the people who own onboarding described their own process in their own words. We anonymize companies by profile, and every figure cited comes from the team it describes, about its own process. None of the figures are averaged, because they aren’t comparable.
“So it’s varied input sources, lukewarm knowledge about the data on the customer side, and then a really inflexible template on our side.”
Everything in this report ties back to that single sentence. Three forces – none of which the implementation manager controls – meeting in a spreadsheet they’re expected to fix in a few days.
Methodology
This Ingestro report brings together insights from 455 recorded conversations with approximately 195 B2B software companies between August 2025 and August 2026. The discussions focused on customer data onboarding, importing, migration, and preparation. They covered initial discovery calls, product demonstrations, technical discussions, proofs of concept, and delivery reviews.
Participants included professionals responsible for customer onboarding, such as implementation and onboarding managers, professional services and customer success leaders, implementation consultants, and solution architects, as well as supporting product and engineering teams.
Industries ranked by representation:
These were working conversations, not a survey instrument. Participants weren’t asked a standard question set, so the findings are qualitative patterns rather than measured frequencies. We don’t report percentages of respondents, because no comparable denominator exists.
Figures are individual, never aggregated. Every number in this report was stated by one team about its own process. We haven’t averaged across companies. The units and scopes are genuinely incommensurable, and an average would be an invention.
Coverage is uneven. Roughly twenty accounts contribute about a third of all conversations, which weights the detail toward payroll, HR, ESG, and compliance. Findings are strongest where several unrelated companies described the same mechanism independently, and we’ve flagged the places where they rest on a single account.
Quotations are verbatim from recorded conversations, lightly trimmed for filler words and never for meaning. Quotations translated from German into English are marked accordingly throughout this report. Company identities are replaced with descriptive profiles throughout, with one named exception published with permission. Where a claim could identify a company through detail rather than name, the detail has been generalized.
Findings
The pipeline
Almost every onboarding process we looked at breaks down into the same four stages. What differs between companies isn’t the stages but which stage software automates and which falls to a person. The critical structural feature is the loop: when validation fails, the work returns to what is often the slowest and least motivated actor in the chain – the customer.
Stage names are our own. The effort distribution reflects where interviewed teams reported spending their time and budget. Teams that automated data preparation without improving data collection saw the bottleneck shift one stage upstream.
Collection
The default model across much of the industry is: send a spreadsheet, wait. It’s so universal that it’s rarely examined. When we asked teams how well it works, the answers were consistently bleak, and the reasons were structural rather than motivational.
“We start the project and then we throw a number of massive Excel files at them and say: have fun. It’s not exactly modern. It feels a bit 1995-ish.”
Implementation managers are measured on go-live dates they don’t control. Repeatedly, teams identified the longest stretch of a project as the interval in which nothing is happening on their side at all.
“It’s the customer actually completing and working through all of the documents and trying to complete them. That’s what really takes the elapsed time, because they’ve got to gather the data, populate the data, check the data, and then we receive them.”
An expense-management vendor running three-to-nine-month implementations described exactly how a delay early on adds up: “If you miss a week or two in the beginning of the project, then all the other steps later are delayed.” The two weeks aren’t lost work. They’re lost sequence.
This was the most consistently under-anticipated finding. Vendors design onboarding as though the customer holds an accurate model of their own data. In outsourced, acquired, or legacy-heavy environments, they often don’t.
“They don’t always know their data either. They don’t even know how it’s calculated any more.”
A DACH HR vendor’s consulting lead described the same gap at the other end of the market: smaller customers, around a hundred employees, “will hand you a piece of paper, if it comes to it.” Data maturity is bimodal, and the same onboarding process has to serve both ends of it.
One finding surfaced only in the detail of how customers obtain their own history, and it has no purely technical fix.
“Some customers don’t actually have access to run reports, and they have to make a formal request to the provider for a full data download. And some customers don’t like to do that, because it signals to the provider that the time might be coming to an end.”
As a result, data arrives piecemeal, assembled from whatever the customer could extract without alerting the incumbent. Elsewhere the constraint is commercial rather than political: one implementation team noted that obtaining the single statutory file that would give them a complete dataset is chargeable on some competitor platforms, so customers send several partial reports to be merged instead.
The most direct statement of the collection problem came from a vendor whose customer base includes owner-operator businesses alongside municipalities.
“We are not a company where customers do it. They can’t do it, they don’t want to do it, they’re busy. A large part of our customer base is maybe a hauler that has five trucks. It’s the guy and his daughter who run the office. They don’t have an IT team.”
Meanwhile the vendors serving the other extreme reported the mirror-image problem: their largest and most valuable customers expect to hand over raw data and have the vendor absorb the reformatting work. As one compliance director described her biggest accounts, “they want to do less and have more.” Neither end of the market seems to want the template.
Preparation
Once the file arrives, almost every team we spoke to does the same thing, using the same tools, and describes it in almost the same words. The transformation layer of the B2B software industry is often a consultant with a spreadsheet open.
“The rule settings available in your software are basically what we would manually be doing in Excel with formulas and VBAs and whatnot.”
“Our team is doing that in various forms. My little team of two is doing the best, because they’re doing it in a semi-automated fashion. But we also have people who are manually touching data, who are writing Excel formulas. We have a variety of messes going on.”
A CRM product manager made a distinction most teams feel but rarely separate: the cost of doing the cleaning, and the cost of explaining the cleaning.
“The biggest problem we have at the moment is everything you need to do to clean up your Excel before you even start the import. It’s the amount of time we spend cleaning it up, but also the amount of making the customer understand what it is that they need to do in Excel rather than in our product, because our product doesn’t clean up.”
Teams that had solved column matching consistently reported that the remaining work was harder: deciding what a value means. This is where domain expertise is trapped, and where the back-and-forth with the customer happens.
“The bulk of the time is actually going back and forth with customers to figure out: does this thing really map to what we think this thing should be?”
“They might call it biofuel XYZ, and we might call it biofuel ABC. So then decisions have to be made about what that maps to within the list of default values we have in our system.”
The same vendor’s team named a second, related task that no importer we encountered addresses: unit conversion with arithmetic. Tonnes to US tons, BTU to MMBTU, liters to kilowatt-hours. Each is a calculation, each is currently done by hand, and each is a place where a silent error becomes an audited number.
At one provider whose onboarding is a paid five-day workshop, the professional-services lead was unambiguous about where that week goes: “The biggest piece of work would be the mapping. It’s making sure that what a particular field is called in one system, you’re mapping to what it’s called in ours.” The artifact at the center of that workshop is a spreadsheet with one tab per API endpoint. Their own assessment: “Currently, we’re on spreadsheets. That’s on our roadmap, to try to get away from this spreadsheet.”
A recurring and largely invisible cost: the template the customer fills in and the file the system ingests are different structures, so a human reconciles them every time. One implementation specialist walked us through a workbook with a deprecated section that must be pasted around, more than ten columns missing relative to the real upload template, and a country variant with roughly fifty property columns of which two or three are ever populated.
“For Spain, we have to convert the pay codes into our template, which involves copying and pasting the columns in a completely different order and actually cherry-picking the right columns out.”
Column-level mapping is the easy case. Implementation teams described transformations that change the structure of the data: splitting one dump into several typed imports; merging one sheet per site into a single target; joining related worksheets on a key that may not exist; splitting a single source column carrying an account number and a site number into two target fields. A workforce vendor summarized the whole class of problem in one line about their own template: either the effort sits with the customer, or it sits with us.
“And the frustration sits mainly with our consulting team.”
Validation
Validation was the stage where teams were most specific about what is broken, and where the diagnosis was most consistent. In almost every current process, validation runs at import, inside the vendor’s system, after the customer has handed off. The result is a loop, not a fix.
“At the moment, if one information is missing, we have to send it back to the customer, let them know what needs to be corrected, wait for them to correct it, and then receive it to be able to do the configuration. So all of this is delaying the project.”
The same team identified the underlying asymmetry, which is worth stating plainly because it helps explain much of the rework in the industry: the customer filling in the template can’t see the system that will judge it. “They received this template from us, so they fill it in with the information they have, and they’re going to figure it out.” Errors like branch not found are only knowable on the vendor’s side.
Illustrative flow assembled from what interviewed teams described. Errors such as “branch not found” can only be known on the vendor’s side; the customer filling in the template can’t see the system that will judge it.
A facilities-software consultant put it most sharply: template validation has a hard ceiling, and it’s not about formulas.
“There’s a lot of checks we cannot really do in Excel. And especially checks that need information about what’s already existing in the system.”
The failures this produces are relational rather than field-level, and they recurred across every vertical: a child record arriving before its parent exists; a contact pointing at a supplier that was never created; a department declared valid in three of four locations; two “unique” contacts sharing an email; the same site appearing in two files. A procurement platform described its workbook as eight interdependent tabs, uploadable days apart, where the real validation question is whether a combination in tab five contradicts something in tab one.
“You can see, okay, here’s an issue, but then if you want to change that, you have to go back to the Excel file, change it, re-upload the whole thing.”
Where the importer is all-or-nothing, the cost keeps adding up. A Nordic vendor migrating its own installed base off an on-premise product, where legacy permissiveness had produced error rates of up to 60% in bad cases, reached the operational conclusion themselves: “It’s a little bit sad that we hold on with the other 90%. Send in the 90%, spit out the 10%, show the customer.”
The recurring example, across every vertical we looked at, is dates. A plausible-looking date is accepted, mis-parsed, and never flagged.
“They weren’t born on the 5th of November. They were born on the 11th of May. And the only way to change things like that is to go into the screen and actually change it on the screen. And that takes a lot of time.”
An EHS product director made the case for institutional memory over generic rules: “Sometimes we’ve got commas because somebody uploaded something with a comma instead of a decimal point and we need it to be fixed. We really do need people who’ve got the sort of trauma of it destroying their implementation.” Teams often learn the rules that matter from incidents, and today those rules typically live in individuals rather than in systems.
Audit trail. In regulated segments, evidence of transformation is a hard gate. A services lead returned to it twice: “We’ll still need to be able to provide the evidence of what was mapped and how it was converted,” for a client’s third-party auditor rather than for internal comfort. A separate, under-served requirement sits alongside it: reconciling aggregate totals before and after cleaning, so that 1,000 kWh in the source file is provably 1,000 kWh in the system.
Reversibility. At the most mature team we spoke to, pre-import validation was already solved and self-service was still blocked, because their own platform has no per-import undo. A customer who uploads to the wrong location can’t be rolled back. This is a product-platform gap rather than an importer gap, and it’s the one that stops the tool being handed to customers.
Integration
Integration was, across the corpus, the least-discussed stage, which is itself the finding. Teams rarely described difficulty writing data into their own system. What they described were the seams around it.
Multi-tab, annotated, color-coded workbooks are collection instruments. The systems behind them typically ingest one flat table at a time: “it’s literally got to be a flat file to upload.” Every workbook therefore tends to imply a hand-run flattening step that nobody planned and nobody owns.
One provider whose primary integration path is a clean API still routes every inbound record into a staging table, where the receiving team verifies, amends, or rejects it before it commits. The manual review was displaced rather than removed, which is worth remembering before treating “we have an API” as evidence that onboarding is automated.
One enterprise platform had already evaluated and rejected a well-known integration vendor for a specific reason: it produced an intermediate format and left the actual load to them. Onboarding teams rarely buy a transformation. They buy a landed record.
The most instructive rejection in the whole corpus had nothing to do with capability. A facilities vendor had turned down a data-onboarding tool earlier, not because it didn’t work, but because embedding it required engineering work they weren’t willing to fund. The conversation only reopened when the same capability became configurable without development. For an implementation manager with no engineering allocation, integration lift is the first filter rather than the last.
Independent of vertical, two questions arrived before any discussion of features: where does the data physically get processed, and what happens to it if an AI model touches it. Browser-local processing, self-hosting, regional hosting, and model-training carve-outs were decisive in more conversations than any mapping capability. An onboarding tooling decision is often also a security review, so plan the timeline accordingly.
The four routes
Nobody we spoke to was doing nothing. Each had chosen a way out, and each could describe, unprompted, the wall at the end of it. The choice is typically determined not by strategy but by which resource the team is allowed to spend.
Ship a stricter template, better instructions, a video, an annotated header row. Make the requirements unambiguous and hold the line.
The email round-trip. Send back, wait, receive, still wrong. One vendor priced it at one to two weeks lost at the front of a three-to-nine-month project, and the delay propagates to every subsequent milestone. It also fails asymmetrically: your smallest customers often can’t comply, and your largest often won’t.
Let consultants pre-clean every file before it goes near the importer. It works, it’s immediate, and it requires no engineering approval.
Margin and price. One EHS leader described losing deals on implementation cost and then absorbing part of the migration expense anyway to close the rest: “It used to be that people understood, okay, data migration, that’s going to be expensive. And now they don’t understand that. They’re like, wait, why should this cost so much?”
Alteryx workflows, Python pipelines, hand-written SQL per import, a validation engine. Industrialize it properly and own it.
Three walls at once: opacity, access, and headcount. This route is often taken by the most sophisticated teams, and the failure is structural rather than technical. The clearest case in the corpus was a multinational compliance provider maintaining roughly 120 client-specific transformation workflows, with an internal ask to extend to around 400, serving a filing team of about 100 people.
The fastest-growing, but least-governed route we saw: onboarding teams use general AI tools to reformat client files into vendor templates.
Unrepeatable, unauditable, and taught from scratch each time. As one implementation manager put it, teams repeatedly teach AI how to handle one provider versus another, but that knowledge doesn’t carry forward. In regulated or DPA-constrained environments, the approach may be prohibited altogether, with one vendor ruling it out on data-protection grounds.
“We’ve got this tool which kind of does that automatically today, albeit it has to be programmed and we can’t really see how it works. It is literally that file in, and then you hopefully get a file out, without being able to interrogate what’s going on in the middle.”
Opacity. The team carrying the regulatory risk can’t inspect the transformation that produces the filing. In this case the incumbent logic had to be reverse-engineered from workflow exports before it could even be rebuilt.
Access. Only a small technical team can change a workflow, so every client variation becomes a ticket with a one-to-two-week cycle. The requirement, as stated by the business owner, was about removing the gate rather than adding features: “Can we do that without needing to involve a technical team? So then month two, three, ten, anyone in the team, any of our managed-services teams, they’ll be able to handle that because it’s intuitive.”
Headcount. A colleague priced the alternative in the only currency that matters: “If we have an SDK, then we’re going to have to have a developer. If we have a developer, it’s going to be pulled off something else.”
“We’ve gotten in this spot where we cannot scale, and we do not want to get back to that.”
A related and under-appreciated problem is how much of this work can depend on one person. At one vendor migrating its installed base off a legacy product, a single person who had owned that system for nine years performed roughly 90% of all data extractions. That’s not a tooling problem until he takes a vacation, and then it’s the only problem.
Note also what migrating off a bespoke layer does not do: it doesn’t remove the need for code. The compliance provider above accepted that merges and rate calculations still require scripting, and solved instead for who can produce it. An internal agent generates transformation logic from documentation, a shared code library accelerates the rest, and a deliberate split has their own team building part of the estate specifically to avoid repeating the dependency.
Teams that do get a flexible importer in place hit a second-order problem, and it’s worth naming because it’s avoidable. The instinct is to build one importer per source system, per competitor, per country. That estate then has to be maintained in lockstep.
“When we started, we started to build kind of multiple importers for the different competitors that we have. That was kind of fine when there was differences with those competitors. But it meant if we made a change that needed to go for all the importers, we had to change each one. And quite honestly, I’d forget to do one of them. And then they were sort of doing different things for the same data.”
The fix that team landed on, collapsing every competitor-specific importer into a single configurable engine with the source selected as an input, is the pattern we would generalize from this research. It’s also, notably, the version of the story they were willing to put their name to.
“With Ingestro, we unified onboarding and replaced separate importers for every competitor with just one Master engine. It’s now much easier to track what needs updating and when.”
Elsewhere in the corpus the same trap appeared as roughly fifteen legacy importers described as a standing maintenance burden, and as ten to fifteen separate import files per client against a library of around a hundred templates.
Ownership
The most striking pattern in the whole corpus isn’t technical. It’s that the people who feel this pain most acutely are almost never the people who control the fix.
Implementation managers, onboarding leads, and professional-services directors own the outcome, the timeline, and the customer relationship. They don’t own the product roadmap, the data model, or engineering capacity. So the problem sits permanently in a gap.
“We are kind of restricted in the sense that anything that requires any actual integration or development with our actual software is not something that is on the table right now, just due to back-end resources.”
On the product side, the reason isn’t neglect but arithmetic: ingest formats rarely outrank customer-facing features. One professional-services manager described it as a settled fact of life. Fixing the data formats “never really rises to the top of the list,” which means the cost stays in the services budget indefinitely, where it’s easier to hide and harder to justify.
There’s also an unresolved question about whose job this even is. One expense vendor argued from principle that it’s not the onboarding manager’s: “It’s not really a responsibility that should fall on the onboarding manager. The purpose of the onboarding is to empower the key users and the future admins so that they can maintain their platform themselves.” A CRM vendor described the opposite reality, where customers routinely say can you do this for us, and hand-holding by service, coaches, and consultants is simply the norm.
Because the cost is distributed, it rarely appears as a line item. The exceptions are instructive.
“It’s just inertia is what it is. It’s hard to get people to change even if what they’re doing is really painful.”
On the record
Each figure below was reported directly by the team involved, and we verified it against the original recording rather than relying on a summary. They aren’t comparable to one another and they aren’t averaged: the units, scopes, and definitions genuinely differ. Where a figure is an estimate the team arrived at on the call rather than something they measure, we label it as such. They’re included because individually they’re specific, and collectively they establish an order of magnitude.
| Reported figure | What it measures | Company profile |
|---|---|---|
| ~150 person-days / yr | Jointly estimated: standardizing 300 to 400 client inventory lists at roughly 180 minutes each, for one formatting step only, handled by a 21-person team. | Insurance brokerage group |
| ~30 days per customer | Data migration by professional services, run at least twice (staging, then production). | Field-operations software vendor |
| 35–40 hours per client | Active working time on an SMB client. The implementation lead’s stated mission is to halve it to 20 hours and reach go-live in under two weeks. | E-commerce channel platform |
| 3–5 days per client | Manual data mapping step inside a 6 to 12 month onboarding cycle. | Financial data platform |
| ~2 weeks per client | From data handover to go-live (engineering migration plus manual QA), even in the smooth cases. | Vertical SaaS vendor |
| ~1 week per submission | Manual upload and KPI mapping of a client Excel submission into an ESG reporting module. Recurring, not one-off. | Regulatory reporting vendor |
| 2 people × ~4 hrs | Cleaning one client Excel file, with up to a week elapsed before all the data is in. | Early-stage B2B platform |
| 1.5–2 hrs → 3.5 min | Per-file processing time for a statutory submission, after automation. The manual figure rises to 3 or 4 hours later in the tax year. | Mid-market HCM vendor, UK |
| 5 paid days | Client onboarding workshop, dominated by spreadsheet field mapping. | ANZ payroll provider |
| 3 wks → 2 hrs–2 days | Time to build one importer after replacing the in-house flow. 21 products in the portfolio, roughly half using the shared importer so far. | European HR platform |
| up to ~1,500 mappings | Supplier-name mappings that did not persist reliably between imports. On a list of about 500 suppliers, re-mapping up to three times. Intermittent, still under investigation at the time of the call. | Carbon accounting platform |
| ~120 workflows | Client-specific transformation workflows maintained by a technical team, with an ask to extend to around 400. | Multinational compliance provider |
| ~15 importers | Legacy importers under maintenance. Clients must conform to the vendor’s specific file formats rather than sending their own. | Workforce compliance vendor |
| 10–15 files per client | Separate import files per customer (a ballpark), drawn from a library of around a hundred templates, with payroll carrying its own set. | European HR vendor |
| 2 vs 20 per month | Customers onboarded per month, capped by manual ingestion, against a forward sales requirement of at least 20 as they scale. | Construction software vendor |
| ~50 tabs | Tabs in the customer-facing import template. 1,000 to 5,000 import activities per year, all via professional services. | North American CMMS vendor |
| up to 60% wrong | Error rate observed in legacy-system data during migration to a SaaS successor. | Nordic project-software vendor |
| up to 8 years | Historical data requested by prospects, priced into the implementation quote. | Enterprise EHS and ESG vendor |
What good looks like
Derived from what teams in this research said was missing, not from a product specification. Score your own process against it. The items are ordered by how often their absence was named as the cause of a delay.
