Smart CV-to-ATS Mapping Without Manual Work

The mapping problem every recruiter knows

You have parsed a CV. The data sits in a row of fields. But now those fields have to land in the right places, in the right formats, in a structure somebody else designed. And that is where the pain starts.

For years the industry treated this as a translation problem. Bullhorn calls it “Current Title”, Carerix uses “Huidige functie”, the next system has its own word for the same thing, and every tool in the middle needed a lookup table between all of them. Same information, different labels, and a maintenance burden that never ends.

That framing hides the real issue. The labels are not the problem. The problem is that the fields belong to somebody else — so when your desk needs one that the vendor never imagined, it goes in a notes field and stops being data. Meanwhile recruiters spend more time filling in boxes than reading the CV. That is not recruitment. That is data entry.

Why standard mapping doesn’t work

Most CV parsers offer fixed mapping. Field A from the CV goes to field B in your system. Sounds logical, and in practice it falls over for three reasons.

First: candidates structure their CVs completely differently. One person puts skills under work experience, another in a separate section. Some mention their job title in the header, others only in the experience section. A fixed table cannot handle that, because the input is not fixed.

Second: fields are not universal. Your model might have a select field for “Industry” with twenty options. The candidate writes “Financial services” on their CV. That does not automatically match “Financial Services” in your list — and a system that writes the raw string anyway has just made your filters unreliable.

Third: every agency has fields it invented for itself. Fields that exist because of how that desk actually works. No standard mapping accounts for those, which is exactly why they end up half-empty.

How AI mapping works differently

Simply’s approach removes the translation step rather than automating it. There is no foreign system on the other side of the mapping: the fields a CV is parsed into are your fields, in your own data model. The system does three things.

It reads the CV and understands context. “Senior Developer at ING, 2020-2024” is not a text line. It is a job title, an employer, a start date and an end date — and each role comes out as its own child record rather than a paragraph in a box. The AI recognises that regardless of how the candidate wrote it.

Then it extracts against the schema you actually have. Because the data model is metadata rather than code, objects, fields and relations are rows you control. A field you added last week is part of the extraction schema this week, without a release, a ticket or a mapping table. Your own objects included.

Finally, the extraction is explicit about what it does not know. If a CV never states a notice period, the notice period stays empty rather than becoming a plausible number a recruiter later quotes to a client. Nationality is never inferred from a name or a language. You can review proposed values before adding them to the record.

Dropdowns, enums, and structured fields

This is where most tools fail. And it is exactly where the difference shows up.

Example: your candidate object has a select field for “Education Level” with options like Bachelor’s, Master’s, Associate’s, PhD. A candidate writes on their CV: “BSc Computer Science, MIT”. A standard parser pastes that entire string into the field. Here the value has to resolve to one of the options that field actually allows, or it does not get written silently — a recruiter reviews the proposed value.

The same logic applies across every field type. A date field behaves like a date, so it sorts and filters like one. A number field will not quietly accept text. A required field stops a record being saved half-empty, and a unique field stops two recruiters creating the same client twice under slightly different spellings. The type is not decoration; it is the rule the value has to satisfy before it lands.

These sound like details. But these details are exactly what separates clean data from polluted records that undermine your entire workflow — because a report is only as good as the field types underneath it.

The CRM side: one system, not two

Mapping used to stop at the ATS and start again at the CRM. Client data in one system, candidate data in another, notes in both, and a nightly job trying to keep them civil.

That whole layer disappears when the ATS and the CRM are the same model. Companies, contacts, jobs, applications, candidates and placements are objects with real relations between them: a placement knows its candidate, its job and its client. There is no second system to push the same information into, so there is nothing to reconcile and no field to map twice.

And if your agency runs workflows nobody else runs? Those become objects and fields you define, not exceptions you work around. Automatic data entry then keeps them current the same way it keeps the standard ones current: the conversation, the message or the document proposes the change, and you approve it.

What this looks like in practice

A recruitment consultant at a mid-sized agency processes an average of eight to twelve CVs per day. Done by hand, each one costs five to ten minutes of typing. That is roughly ninety minutes a day retyping information that is already on the CV in front of you.

With extraction against your own model, the typing step is gone. What remains is reviewing: the CV is parsed, the values arrive as proposals on the candidate record, and you approve them — reviewing proposed values rather than re-entering the lot. Those ninety minutes go back into conversations, business development, or your pipeline.

Over a month that is a meaningful fraction of a working week. And the data that lands is cleaner than the manual version, not because the AI is smarter than you, but because it does not get bored on the eleventh CV of the day and it never has to be trusted blindly — every value it proposed is one you said yes to.

What actually connects, and what does not

Worth being blunt here, because it is the question every buyer asks eventually.

Simply does not sync with another ATS. Not Bullhorn, not Carerix, not anything else in that category — and not because it would be technically hard. Two systems of record writing to each other gives you two systems of record and no truth, and the weekly reconciliation lands on your team forever.

What does connect is a short list you can check: Google Calendar and Zoom for meetings, Gmail and Outlook for mail, Slack for the team, and HubSpot for the commercial side. Six connectors, named, all of them built. Anything outside that list is a public API key and a signed webhook rather than a promise on a slide.

Coming from another system is a migration, not an integration: a one-way import over about four weeks. The part that matters most for this article is the field-mapping session — your current fields on the left, the new model on the right, walked one at a time. Every field gets one of three outcomes. It maps one to one, which is by far the biggest pile. It does not exist yet, in which case we create it, and you can report on it the same day. Or it is a leftover from a process you no longer run, and we write down that it is not coming rather than letting it quietly disappear.

And for agencies whose clients each want something different in the intake: that is fields and objects inside one model, not a second configuration of somebody else’s system. You are not switching between setups. You are describing your own work once.

The role of validation and transparency

AI that fills in data without letting you verify what happened? Nobody wants that. That is why every extracted value is traceable back to where it came from.

Review each proposed value against the CV and your data model. You can adjust it before adding it to the record.

Underneath that sits the audit log, written in the same transaction as the change it describes — including attempts that were denied. Nothing falls behind, and nobody has to reconstruct months later who approved a value that turned out to be wrong. That is the difference between a system you can defend in a client conversation and one you can only apologise for.

From data entry to recruitment

The core of smart CV mapping is not the technology. It is what it gives you back. When you no longer have to manually enter data, you can do what you are good at: evaluating people, building relationships, and placing the right candidate in the right role.

That is not a future promise. That is what agencies are doing today. And it starts with a CV you upload.

Curious how it works? Read how to eliminate manual CV processing, or try it yourself — fourteen days, the full product, no card.

Smart mapping for complex ATS configurations

The challenge in CV-to-ATS mapping grows as the configuration gets more complex. Most agencies have accumulated custom fields, adapted workflows and specific validation rules over the years, and a system that only handles the standard shape pushes all of that into free text. Here the model is yours to define, so the extraction targets your field types and your rules rather than a template’s.

A concrete example: suppose you have a select field for ‘experience level’ with five options — junior, mid-level, senior, lead, expert. When a candidate says in a conversation ‘I have eight years of experience and manage a team of four’, the system can propose ‘lead’ as the value for that field. It proposes; you approve. What it does not do is paste the sentence into a free-text box and leave the interpretation to whoever reads it next.

That is what prevents the familiar situation where automation produces a polluted database. When free text lands in structured fields, your reports and filters stop being trustworthy — and reporting is where that damage surfaces, usually in front of a client. Smart mapping means every value fits the field it lands in, whether that is a select, a date, a number or a relation to another record.

The validation process in automatic mapping

Review remains important in automated mapping. Compare proposed values with the candidate’s information and adjust them where needed. You decide what ends up in the record.

That transparency is what makes the automation usable rather than merely impressive. A recruiter who can see where a value came from will let the system do the typing. A recruiter who cannot will check everything by hand anyway, and you have bought nothing.