Excel import

Move your organisation, people, their children, balances and time off into mTime with an ordinary Excel workbook — the format to reach for when the data comes out of a payroll or time system you are leaving behind.

Overview

The Simple Excel format is a single .xlsx workbook with five sheets:

You can open it, read it, and edit it in Excel, Numbers, or Google Sheets. That is the whole point: it is the format for onboarding a company’s employees in bulk, for mass edits, and for a migration from another system.

It is not the same thing as the full workspace backup:

Getting a workbook to start from

You have two starting points, and both are better than building the file from scratch — they already carry the exact column headers, your workspace’s live account names, and a column for every attribute you have defined.

A blank template. Go to Admin › Data Import and click Download template . You get import-template.xlsx, generated for your workspace: all five sheets, a Guide sheet that opens first, greyed example rows to overwrite, one column per time account, and one column per attribute.

The template is written in your workspace’s language — the sheet tabs as well as the column headers. The arrow beside the button offers the other six languages mTime speaks, so a consultant working in an English workspace can hand a Danish colleague a Danish sheet, with tabs named Medarbejdere, Tidskonti, Børn and so on.

A filled export. Go to Admin › Data Export, choose the Simple Excel format and click Export . You get the same columns — minus the Absence and Children sheets, which are import-only — with your current employees, attribute values and balances already in them. Edit and import it back: the round trip is safe, because the export writes the identifiers and names the import expects.

The export offers three options:

• Employees only — leave out the Accounts sheet
• Anonymize personal data — replace names, emails and contact details with placeholders. Attribute cells are emptied too, on both the Employees and the Org Units sheet: an attribute can hold anything, so an anonymised export cannot know which ones are safe to keep. An anonymised export is for sharing a copy of the data, not for editing and importing back: importing it would replace everyone’s names and emails with the placeholders.
• Employee data scope — export one employee, one org unit, or everyone

What is in the template

• Guide — the sheet the workbook opens on. It says what each sheet is for, what every column means, and what the colours on the header row mean. It also records which version of the template it is, which language it was generated in, and which workspace it came from, which is worth having when a file has been passed around for a fortnight before it comes back to you.
• The five data sheets — Org Units, Employees, Accounts, Absence and Children.
• Lists — the values behind the dropdowns.

Guide and Lists are not read by the import. Leave them in the file or delete them, as you prefer.

The header row is colour-coded, so you can see at a glance what a sheet insists on:

The rarely-used columns on the Employees sheet — phone, mobile and the postal address — are grouped at the right-hand end and folded away. The day columns Mon … Sun are folded into a group of their own, just before Weekly Norm. Click the + above a group to open it. Both still import when you fill them in — most imports never need to. The Guide sheet spells out the legend, and lists every sheet’s required columns in one place.

Several columns offer a dropdown. They warn rather than block, on purpose: the Employees sheet may legitimately name an org unit that the Org Units sheet creates in the same import, and a hard stop would make that impossible to type.

Greyed example rows show the shape a value is expected to have — initials in Employee ID, a child unit naming its parent. They are placeholders: overwrite them, or delete the rows.

How mTime reads the workbook

A few rules apply to the whole file. They are worth reading once, because most failed imports come from here rather than from the data itself.

• The sheets must be named Org Units, Employees, Accounts, Absence and Children, or by their name in any of mTime’s languages, as the template writes them (Medarbejdere, Børn, Dipendenti, …). The English names always work. Any other sheet in the workbook is ignored, including the template’s own Guide and Lists sheets. A workbook with only some of the five is fine.
• The column headers are in a language, and mTime reads all seven. A generated workbook is headed in your workspace’s language, or in whichever language you picked when you downloaded it, and mTime recognises a built-in column by its header in any of the seven. So a workbook generated in Danish imports for an administrator working in English, and a sheet that somebody has half-retyped in another language still works. A generated header also carries a marker your spreadsheet does not display, naming the column exactly — which is what keeps a column importing after the file has been translated or an attribute renamed.
• A header you type yourself works too, as long as you write it the way mTime writes it in one of those seven languages. Upper and lower case and stray spaces do not matter; a word of your own does. That is why the safest file is one mTime generated: edit the template or an export rather than building a workbook from nothing.
• Row 1 is the header row. Every following row is data.
• Columns are matched by their header, not by their position. You can reorder columns freely.
• Completely empty rows are skipped, so trailing blank rows at the bottom of a sheet do no harm.
• A column mTime does not recognise is ignored — and reported. On the Org Units, Employees, Absence and Children sheets you are welcome to keep a note alongside the data. Two kinds of header are no longer just a note: External ID is read on both the Org Units and the Employees sheet, and is where your old system’s record number belongs — and so is a column named after one of your workspace’s own attributes. The Review step lists every column it ignored, quoted exactly as you spelled it, and suggests the column you probably meant where its position gives it away. It is a warning, not an error: your scratch column is safe and the import runs, but a misspelled header is caught before the import rather than after. On the Accounts sheet the opposite is still true: every column that is not Employee ID, Full Name, or Import Date is read as a time account, so a stray column there causes an error.
• Dates can be real date cells, or text written as YYYY-MM-DD. If the cell is a date to Excel — which is what you get when you type 01/05/1990 into a normal cell, or pick from a date picker — mTime reads the date itself, so your local date format is fine and you do not have to reformat anything. If the cell is text, it has to be YYYY-MM-DD, for example 1990-05-01: text carries no date format, so 03/04/2026 could mean March 4th or April 3rd and mTime will not guess. The template and the export write text in YYYY-MM-DD form.
• Numbers use a period as the decimal separator (7.4, not 7,4), with no thousands separator. Type numbers as numbers and Excel handles this for you; the risk is with values pasted in as text.

Attribute columns

Besides their built-in columns, the Employees and Org Units sheets carry one column per attribute your workspace defines — the way the Accounts sheet carries one column per time account. Cost centre, badge number, payroll number, job title: whatever you keep on your people and your teams travels with them. Attributes are set up under custom attributes.

The Employees sheet carries two levels at once: the employee’s own attributes, and the attributes of their employment — the contract — such as Title and Employment Number. You do not have to keep the two apart yourself; each column knows which of them it belongs to.

Which attributes get a column

The sensitive row is the one that looks inconsistent, so it is worth a sentence. An export is produced in the background, and mTime cannot know who will end up opening the file, so it never writes a sensitive value into a spreadsheet. Reading one in discloses nothing: whoever fills the cell in already has the value in front of them. So mTime accepts a column it would not write for you.

An attribute a connected system manages is left out in both directions. That system is the system of record for it and would overwrite whatever you imported at its next sync, so a row that fills such a column in is rejected with the reason rather than quietly dropped.

Filling the columns in

Each column is headed with the attribute’s name. If two attributes share a name — an employee one and an employment one both called “Title”, say — each is headed with its key instead, so you can still tell them apart. If you build the file yourself, head the column with the attribute’s name as it appears under Settings › Attributes — or with its key, which also works and never changes when somebody renames the attribute. Matching ignores upper and lower case and surrounding spaces, so cost centre finds Cost Centre.

Values have to match the attribute’s type. A cell that does not fit is a row error on the Review step, naming the column and what is wrong with it:

• An attribute marked Unique is checked against the workspace and against the rest of the sheet. A clash is reported on the row and names the column — never the value, because these are the columns a national identity number arrives in.
• Employment attributes apply on updates too. They are written to the employment running today, or to the most recent one if nobody is employed today. This is unlike the other employment columns — Org Unit, Manager, Terms, the dates and the norm — which are only used when a row creates somebody. A row that fills in an employment attribute for a person with no employment at all is a row error: there would be nowhere to put the value.

Adding an attribute from the sheet

The template leaves one spare column headed New attribute at the right-hand end of the Employees and Org Units sheets, to show where a new one goes. Type a name over it, fill in the values, and the import creates the attribute on your workspace as a text attribute and stores what you typed in it. It turns up in your settings afterwards, where you can give it a description, a type or a set of options. For a second attribute, add another column beside it — nothing about the spare column is special except that an empty one is ignored.

The attribute is only created if at least one row actually fills the column in, so a spare column you left empty costs nothing.

Two things the sheet will not do. It will not invent one of mTime’s own standard attributes — those have keys beginning with an underscore, and you add the one you want under custom attributes first, then download the template again and the column is there. And it will not write to an attribute a connected system manages.

The Org Units sheet

This sheet builds your organisation structure — the departments, teams and regions the Org Unit column on the Employees sheet points at. It is applied before the Employees sheet, so the same workbook can create a department and put people in it.

What identifies an org unit

There is no ID column here. A unit is identified by its External ID when you fill that column in, and by its name otherwise — and the name is also how the Employees sheet refers to a unit.

Matching ignores upper and lower case, so sales updates Sales and ou-7 finds OU-7.

Column reference

Building the hierarchy

Parent refers to another unit by name — one that already exists in mTime, or one created by another row of this same sheet. The order of the rows does not matter: a parent listed below its children is found just as well as one listed above them.

Name        | Description      | Parent | Head                 | Country
Sales West  | Western region   | Sales  |                      | DK
Sales       | Sales department |        | jane.doe@example.com | DK

A row is rejected if its Parent names nothing, names two different units, or would put the unit inside its own subtree — a unit cannot be its own parent, and A cannot sit under B while B sits under A.

What an update changes, and what it leaves alone

A row writes Name, Description, Parent, Head and Country, and a blank cell clears the value. Two kinds of column work differently, and a blank cell in either leaves the stored value alone: External ID, so an empty column never wipes your identifiers, and the attribute columns, so a half-filled sheet never wipes a cost centre. Everything the sheet does not carry at all is left exactly as it was.

The Head has to be somebody already in mTime. Org units are applied before the Employees sheet, so a person the same workbook is about to create cannot be a unit’s head yet — set the head afterwards on the org unit’s page.

The Employees sheet

The Employee ID column

This one column decides whether a row creates a new person or updates an existing one, and it is what ties the Employees, Accounts and Absence sheets together. It accepts three kinds of value:

The middle option is the one that matters for a migration. Because EMP-4711 always points to the same person in the same workspace, you can:

• reference the same person from the Employees, Accounts and Absence sheets,
• re-run a corrected file and have it update people rather than duplicate them,
• keep your old system’s staff number as the link between the two systems — it is stored on the employee as their External ID , where you can see it, and the export writes it back out.

When the cell is text, mTime looks for the person in this order:

1. the identifier that text stands for — the person an earlier import with the same text created;
2. an employee whose External ID is that text, whoever put it there: an earlier import, the API, or your identity provider;
3. nobody matched, so a new employee is created, carrying that text as their External ID.

Step 2 is what makes the number durable. Somebody already in mTime with EMP-4711 on their record is updated by a row naming EMP-4711, even if that person never came from a workbook — before, such a row silently created a second copy of them.

Column reference

Org Unit, Manager, and Terms are matched by name, ignoring upper and lower case. The name has to be unique: if two org units are called “Support”, the row is rejected and you have to rename one of them first. Terms references records that must already exist — an Excel import never creates a set of employment terms. The other two may point at something the same workbook creates: Org Unit at a unit on the Org Units sheet, and Manager at another row of the Employees sheet, because managers are employees like everybody else.

What an update changes

When a row matches an existing employee, mTime writes every personal column from that row: name, email, birth date, phone, mobile, and the address.

External ID is one of two exceptions to that rule: a blank cell — or no column at all — never clears it. An external id is often the link something else relies on, so mTime only writes it when you put a value in the cell. To remove one, clear it on the employee’s page in mTime.

The attribute columns are the other exception, for much the same reason: a blank attribute cell leaves the stored value alone, and no cell on the sheet can clear an attribute at all.

Two people cannot share an external id. A row that would give one person a value another employee already has is rejected at validation, as are two rows on the same sheet handing the same value to two different people.

The employment works the other way round: Org Unit, Manager, Terms, Employment Start, Employment End, Weekly Norm, and the day columns are only used when the row creates a new employee. On an existing employee they are ignored, and their employment is left untouched. To change someone’s employment afterwards, use their employee page or a bulk change. Employment attributes are the exception to that: a filled-in attribute cell is written to an existing employment as well as to a new one.

Employment and the weekly norm

An employee is only given an employment when Employment Start is filled in. Leave it blank and you get a person in the workspace with no employment — occasionally useful, but rarely what you want, and a row that fills in an employment attribute without it is rejected.

The work-time norm can be given in two ways, and you can combine them:

• Weekly Norm alone — the contracted hours per week, e.g. 37. No day-by-day distribution is stored.
• Mon … Sun alone — the norm is the sum of the days, spread as you wrote it.
• Both — they must agree. Weekly Norm 37 with 7.4 on Monday to Friday is accepted; 37 with 8 on five days is rejected.

Hours are decimal hours, not hours and minutes: seven and a half hours is 7.5, not 7.30. Values are rounded to the nearest minute. The norm must be greater than zero, and it describes a single week — repeating multi-week patterns cannot be imported and have to be set up on the employee.

The Accounts sheet

This sheet sets the current balance of each time account — the vacation days, flex hours, and other balances people are bringing with them.

Column reference

This is the one sheet with no attribute columns: its rule is that every column which is not one of the three above is a time account, and an attribute column would have to fight it.

The account columns

Every remaining column is a time account, named after the account with its unit in parentheses:

Employee ID | Full Name  | Import Date | Vacation (days) | Flex (minutes)
EMP-4711    | Jane Doe   | 2026-01-01  | 12.5            | 450

• The part before the parentheses must match the name of a time account in your workspace, ignoring upper and lower case.
• The unit in parentheses is optional, but when it is there it has to match the account. This is a guard: it stops a column of vacation days from silently ending up in an hours account.
• Day-based accounts are in decimal days — 12.5 means twelve and a half days.
• Hour-based accounts are in minutes — 450 means 7 hours 30 minutes. This trips people up; multiply your hours by 60.
• Negative balances are allowed, for example a flex account in deficit.

The template and the export both fill these headers in from your workspace, which is the easiest way to get them right.

How a balance is applied

Each filled-in cell sets the balance to that value on Import Date. It is not added to what is already there. The entry shows up in the account’s history with the reason “Excel import”.

Because the value is a target rather than a movement, importing the same file twice does not double anyone’s vacation balance. It also means a careless import can flatten balances that were correct — the Review step tells you how many balance changes are about to be made, so check that number before you confirm.

Set Import Date to your cut-over date: the day the balances were true in the old system. Anything mTime records after that date is added on top.

The Absence sheet

This sheet records time off — the history from the old system and the time off people had already planned in it — so a migration does not end with weeks of re-typing time off. One row is one period of time off: who, which type, from when to when.

Column reference

Already deducted, or not yet?

The balances on the Accounts sheet are the balances as they stood at your cut-over date, so the two kinds of time off must be treated differently:

• Time off that had already happened by then is already subtracted from those balances. mTime records it in full — it shows on the calendar, the timesheet and in reports — but never touches the balance again. Deducting it a second time would be wrong.
• Time off planned for after the cut-over is not in those balances yet. It applies as a normal registration and consumes the balance when it happens, exactly as if it had been requested in mTime.

Leave Already Deducted blank and mTime fills it in from the row’s Import Date:

The column is ignored for time off types that never touch a balance, such as sickness under most policies.

Requested time off

A row with Status set to Requested goes to the employee’s approver as a pending request, like a request made in mTime. An employee with nobody to approve for them gets the time off recorded as approved instead of pending forever.

Re-running, corrections, and what the sheet never does

A row on the Absence sheet is identified by its employee, type and dates. Importing the same file again skips rows already imported — nothing is doubled. The sheet only ever adds time off: it cannot change or cancel it. To fix time off imported with the wrong dates or type, cancel it in mTime and import or enter the corrected one.

Two rows for the same employee may not overlap — a vacation interrupted by sickness is two rows for the vacation (before and after) plus one for the sickness, not overlapping ranges. Overlap with time off already in mTime follows the product’s usual rules, so avoid re-importing periods that were entered by hand.

Unlike the first three sheets, Absence is import-only: the Simple Excel export does not include it. The template carries it empty, ready to fill in — an example row left in by mistake would import made-up absence onto a real person.

The Children sheet

This sheet registers employees’ children — what child-related entitlements, such as care days, are granted on. One row is one child, with the same details you can enter under Children on the employee’s page.

Column reference

Every row needs Child Birth Date or Due Date — or both.

Born or expected

A child with only a Due Date is registered as expected. Entitlements that depend on a birth, care days among them, start only once a birth date is on record — so never put an expected date in Child Birth Date, even when the birth is days away.

When the child is born, fill in Child Birth Date on the same row, keep the Due Date, and import again. The due date finds the child you registered as expected, and the import confirms the birth instead of registering a second child.

Re-running, corrections, and what the sheet never does

A row matches a child the employee already has when the birth date or the due date is the same, and so is the name (ignoring upper and lower case). A child without a name, or a row without one, is matched on the dates alone — so adding a name later fills it in rather than registering the child twice. A row with a name looks for the child with that name first, and only falls back to a nameless child with the same date when there is none — so twins where only one is named yet stay two children. A matching row only fills in what the child is missing — a birth date, a due date, or a parent role where none is recorded yet. A role already on the child is not changed. A blank cell never clears anything. A row that matches no child registers a new one.

So importing the same file again changes nothing. Twins are two rows with the same birth date and different names; two rows with the same name and the same date are both rejected, because mTime cannot tell whether they are one child or two.

Like Absence, the Children sheet is import-only: the Simple Excel export does not include it, and the template carries it empty.

Running the import

The wizard is the same one described under Data import, with two differences: mTime recognises an Excel file by its .xlsx extension, and the Merge/Restore choice is replaced by a choice of sheet.

1. Go to Admin › Data Import and click Import .

2. File — pick your .xlsx file. Maximum size is 100 MB.

3. Parameters — choose which sheet to apply, then click Validate :

   Choice	What is imported
   Everything	All five sheets, in order: org units, then employees and their children, then accounts, then time off — so each can refer to something created by the one before it
   Org units	The Org Units sheet only
   Employees	The Employees and Children sheets
   Accounts	The Accounts sheet only
   Absence	The Absence sheet only

4. Review — validation runs on the server without changing anything. You get a count per sheet — org units, employees, children, balance cells, time off — a message for every rejected row, and a warning for anything mTime is going to ignore, such as a column it does not recognise. Warnings do not stop the import; errors do. Fix the file and try again, or click Run import .

5. Results — the outcome per sheet, with a detailed report you can download.

If validation flags the wrong choice of sheet, go Back and validate again — the file stays on the server and does not need re-uploading.

Importing from another system

This is what the format was built for: taking employees and balances out of a payroll or time-registration system and into mTime. The sequence below keeps the risky parts small and reversible.

1. Build the configuration in mTime first

Apart from org units and attributes, the Excel import references configuration by name and never creates it. Before you import anything, set up:

• Employment terms — the contract types your people are on
• Time accounts — every balance you intend to carry over, with the right unit
• Holiday calendars and time off policies, so the balances behave correctly afterwards
• Attributes — one for each field your old system had that mTime has no standard place for, and the standard ones such as Social Security Number or Payroll Number. Download the template after you have added them and the columns are there

Org units are the exception: put them on the Org Units sheet and the import builds the structure for you. You only need to create them by hand if you would rather have the hierarchy in place before the first file arrives.

Make sure the names are unique. Two org units with the same name will reject every row that points at them.

2. Choose your key

Put your old system’s staff or payroll number in the Employee ID column, on every sheet you use. This is the single most valuable decision in the whole migration:

• it links each balance and absence row to the right person,
• it makes the import repeatable, so a corrected file updates instead of duplicating,
• it stays a readable link back to the old system if you ever need to reconcile — mTime keeps the value as the employee’s External ID.

Do the same for your org units, in their External ID column, and you can rename a department later from the sheet instead of by hand.

3. Map your old fields

Export your source data and map it onto the columns. A typical mapping:

Managers are employees like everybody else, so they come in through the Employees sheet — and a row may point at a manager the same workbook is creating. The whole org chart imports in one pass; the management layer does not need a run of its own. mTime looks for the name or email address among the rows of the file first, and then among the people already in the workspace. What it will not do is guess: if two rows carry the same name, or a name matches both a row of the file and a different person already in mTime, those rows are rejected. The email address is the way to be unambiguous.

4. Clean up dates and numbers

Before the first import, go through the file once:

• Date columns hold real dates, not text that merely looks like one. A cell Excel right-aligns as a date is read whatever format it shows; a text cell has to say YYYY-MM-DD.
• Decimals use a period, not a comma.
• No thousands separators, no units, no stray characters — 450, never 450 min or 7,5 h.
• Hour-based balances converted to minutes.
• Selection attributes hold one of the options you defined, spelled the same way.

5. Import in waves

Do not do it all in one go the first time.

Wave one — structure. Import with the Org units sheet selected. Look at the organisation tree in mTime: is everything under the right parent, with nothing duplicated?

Wave two — people. Import the same workbook with the Employees sheet selected. Check a handful of employees in the app: are they in the right org unit, on the right terms, with the right weekly norm, with their attributes filled in? The Children sheet comes in with this wave, so check their children too.

Wave three — balances. Import it again with the Accounts sheet selected, with Import Date set to your cut-over date. Check the balances of the same handful of people.

Wave four — time off. Import it once more with the Absence sheet selected, Import Date again set to the cut-over. Open one employee’s calendar and check their history is there, and that their balance did not move — history is already in the balances you just imported.

Splitting the migration this way means a mistake in the balance columns cannot damage the employee records you have just verified, and vice versa — and a structure you have already checked is a much better place to put people.

Once you have done a migration or two and trust the file, Everything does all five sheets in one pass, in the same order, so units and people created in that import can be referenced immediately.

6. Check the result

Export the workspace again in the Simple Excel format and compare it with your source file. Anything that did not come across shows up as a difference, and the export is a good record of what the workspace looked like at go-live.

Sensitive attributes are the one thing you will not find in that export — mTime never writes them into a spreadsheet. Check those on an employee’s own page instead.

Re-running and corrections

An Excel import is safe to repeat as long as the Employee ID values stay the same. Fix the source file and import it again:

• employees are updated, not duplicated,
• balances are set to the corrected value rather than added on top,
• time off rows already imported are skipped, never doubled,
• children already registered are matched and only filled in, never registered twice,
• attribute values are overwritten where you filled a cell in and left alone where you did not,
• employees that you removed from the file are left untouched — the import never deletes.

The one thing a second run cannot do is change an employment. Employment columns are only applied when the employee is created, so if you got the org unit or the weekly norm wrong, correct it on the employee page or with a bulk change. Employment attributes are the exception and can be corrected by a second import.

Something that does not fit?

The workbook now carries the organisation structure, people, their children, their attributes, their balances and their time off. If you have data that does not fit it, contact support through the in-product help system before you start. Tell us what you are moving and we will find the best route for it.

Validation messages

Validation runs before anything is written and reports the sheet and row of every problem. Rows are numbered as they are in Excel, so “Employees row 2” is the first row under the headers. Errors have to be fixed before the import will run; warnings are for information and do not stop it.

Warnings

Errors

Limits

Permissions

Downloading the template, uploading, and running an Excel import all require the import permission. Producing a Simple Excel workbook from the workspace requires the export permission.