Connect Excel to Google Calendar when the schedule starts in a sheet
A schedule that lives in a spreadsheet is usually there for a good reason. The term timetable, the shift roster, the delivery plan or the conference programme got built in Excel because rows and formulas were the fastest way to think it through. The trouble starts the moment those rows have to become events that other people can see on a phone.
Google Calendar does accept a spreadsheet, but only in one narrow form, and the import discards several columns that whoever built the sheet would consider essential. Knowing in advance what survives the trip is what decides whether this is a ten minute job done once, or a chore that comes back every week.
Three different jobs hide behind the word connect
The searches that lead here are not all asking for the same thing, and the right mechanism is different for each.
The first job is a one-time move. A sheet was used to plan something, the plan is now final, and the events need to exist in Google Calendar from today onward. Nothing will be edited in the sheet again. This is the job that the built-in CSV import was designed for, and it is the only one of the three that Google supports out of the box.
The second job is publication from a sheet that keeps changing. The roster is rebuilt every Friday, a row moves, a shift gets reassigned, and the calendar has to follow. This is a genuinely harder problem, because it needs a notion of which calendar event corresponds to which row. A plain import has no such notion. Import the sheet twice and every event exists twice.
The third job runs in the opposite direction. The calendar is already the record, and the sheet is wanted for counting: hours by client, meetings by team, room usage by week. Nothing needs to be created in the calendar at all. What is needed is a readable copy of what is already there.
Most of the frustration around this topic comes from picking the mechanism for job one and then trying to use it for job two. The rest of this covers each in order, starting with the import, because even the people who need job two should understand the import's limits before building anything on top of it.
The import Google actually supports
The import lives in the browser, not in the mobile app, and it accepts .ics and .csv files on a computer. The path is Settings, then Import and export, then Select file from your computer. The file has to be chosen from local storage, and the target calendar is picked in the same panel. By default events land on the primary calendar, which is worth changing if the intention was to keep the imported batch separable later.
Before that, the workbook has to be saved as CSV rather than .xlsx. Excel's Save As dialog offers comma separated values directly, and only the active sheet is written out, so a workbook with the roster on one tab and the lookup tables on another exports just the tab that is in front.
The header row is where most attempts fail. Google reads English header names, and only two of them are mandatory.
| Header | Required | What it holds | Example from Google's documentation |
|---|---|---|---|
| Subject | Yes | The name of the event | Final exam |
| Start Date | Yes | The first day of the event | 05/30/2020 |
| Start Time | No | The time the event begins | 10:00 AM |
| End Date | No | The last day of the event | 05/30/2020 |
| End Time | No | The time the event ends | 1:00 PM |
| All Day Event | No | True or False | False |
| Description | No | Notes about the event | "50 multiple choice questions" |
| Location | No | Where the event happens | "Columbia, Schermerhorn 614" |
| Private | No | True or False | True |
That list is the whole vocabulary. A column called Attendees, Colour, Reminder, Time Zone or Category is not an error; it is simply ignored. Google states the constraint plainly in its own help page.
The first row of your new spreadsheet includes headers like "Subject" and "Start Date." To import into Google Calendar, the headers must be in English. Source: support.google.com
An English header requirement catches out anyone working in a localised Excel, because the temptation is to translate the column names for the colleagues who maintain the sheet. The workable compromise is a separate export tab whose headers are in English and whose cells reference the working tab.
What the import leaves behind
Three losses matter enough to plan around.
Guests do not come across. Google's documentation is explicit that when an event is imported, guests and conference data for that event are not imported. So a sheet with an email column produces events with nobody invited and no meeting link, and the invitations have to be sent afterwards, event by event. For a twelve row programme that is tolerable. For a two hundred row one it is the reason to stop and choose a different route.
Repeats are flattened. A CSV has no field for a recurrence rule, and Google warns that repeat events imported from a .csv file may not show up as repeating. They arrive as a series of one-time events instead. In practice that is often acceptable, because a flat series behaves predictably. It becomes a problem later, when the whole series needs to move or end, and there is no parent event to edit.
Notifications are not in the file either, which means imported events inherit whatever the destination calendar is set to give new events. Calendar-level notification settings determine notifications for new events unless a specific event overrides them, so it is worth setting those defaults on the destination calendar before the import rather than opening two hundred events afterwards.
One more caution applies when the source is another Google account rather than Excel: imported events do not stay in sync between two accounts. Sharing the calendar is the mechanism for that, not importing it.
The formatting that causes most failed imports
An import that returns an error almost always has a formatting cause, and there are four usual suspects.
Dates are written in month, day, year order in Google's own examples, as in 05/30/2020. A CSV stores what the cell displays, so a workbook whose regional settings display 30/05/2020 will hand over day, month, year and either fail or land events in the wrong month. The safest fix is to build the export column with a text formula that forces the order rather than trusting the display format.
Times take the twelve hour form with AM or PM, as in 10:00 AM and 1:00 PM. A 24 hour column is worth converting in the export tab for the same reason.
Commas inside text need quotation marks around the whole value. Google's own example, "Columbia, Schermerhorn 614", is quoted for exactly this reason. Excel normally adds the quotes itself when it writes the CSV, but a description assembled with a formula and pasted as plain text can arrive unquoted and split across columns.
The True and False columns want those words, not 1 and 0 and not TRUE() formulas that evaluate to something else once flattened. All Day Event takes True for an all-day event and False otherwise, and Private works the same way.
When the sheet stays the source of truth
For job two, the question is not which file format to use but where the link between a row and an event is going to live. Four routes are realistic, and they differ mostly in how much of that bookkeeping has to be built.
| Route | Handles repeats | Brings guests | Runs without a person | Main limitation |
|---|---|---|---|---|
| Manual CSV import each week | No, events arrive flat | No | No | Re-importing duplicates everything already there |
| Apps Script bound to a Google Sheet | Yes, the Calendar service creates recurring events | Yes | Yes, on a time-driven trigger | Someone has to own and maintain the script |
| Paid sync service between a sheet and a calendar | Varies by product | Varies by product | Yes | Recurring cost, and the data passes through a third party |
| Rebuild the events from the text, in a calendar app | Yes, if the app parses repeat wording | Yes, if the app parses addresses | No | Still a manual step, just a much shorter one |
The second row is the honest answer for a roster that changes weekly. Moving the sheet to Google Sheets and writing a script against the Apps Script Calendar service gives access to recurring events, guests and event IDs, and an installable time-driven trigger can run it on a schedule. Storing the created event ID back in a hidden column on each row is what turns a re-import into an update rather than a duplicate. It is real software, with a real owner, and it is worth being honest about that before starting.
The fourth row is the one people underestimate. When the weekly volume is five or ten events rather than two hundred, reconstructing them from a pasted block of text in a desktop calendar is often faster than maintaining any pipeline, particularly when the calendar app reads dates, places, guests and repeat wording out of an ordinary sentence. The way that kind of entry works is covered in Entering events.
Getting calendar data back into a sheet
Job three has no Excel connector at all on Google's side, and it helps to know that before hunting for one.
What Google offers is an export in .ics form. All calendars at once produces a .zip file containing one .ics per calendar, and a single calendar exports as one .ics. The export is only available in a browser, not the mobile app, and it requires the "Make changes and manage sharing" permission on the calendar in question, which matters when the calendar belongs to someone else.
An .ics file is plain text in the iCalendar format defined by RFC 5545, so it is parseable, and that is the route most reporting tools take internally. It is not a spreadsheet, though. Opening it in Excel gives one long column of BEGIN, DTSTART and SUMMARY lines rather than rows.
That leaves two practical paths. A script in a Google Sheet can read the calendar directly and write one row per event, which is the same tooling as the publication job and often worth building once for both directions. Alternatively a commercial add-in can pull events into a workbook on a refresh, at a per-seat cost. For a one-off count, exporting the .ics and parsing it once is usually quicker than either.
What to change first
Decide which of the three jobs is actually in front of you before touching a file, because the CSV import solves only the first one and re-running it is what creates duplicates. If the sheet is a one-time plan, build an English-header export tab, then set the destination calendar's default notifications before importing rather than after.
If the volume is small and recurring, the cheaper fix is to shorten the entry step instead of automating it. Caltimate turns pasted text and spoken sentences into events on a Mac, which removes the spreadsheet from the loop entirely.
Frequently asked questions
Can an .xlsx file be imported into Google Calendar directly?
No. The import accepts .csv and .ics files only, so the workbook has to be saved as comma separated values first. Excel writes only the active sheet when saving as CSV, so put the export columns on their own tab and make it the active one before saving.
Why did the imported events lose their guests?
Google does not import guests or conference data with an event, and a CSV has no header for either. The events arrive with no attendees and no meeting link, and the invitations have to be sent afterwards. For large batches this is the strongest argument for a script-based route instead of a file import.
How do you undo an import that went in wrong?
Import into a new secondary calendar rather than the primary one, and a bad batch can be removed by deleting that whole calendar instead of picking events off one at a time. If the batch already landed on the primary calendar, deleted events sit in that calendar's trash for 30 days, which gives a window to restore them.
Can the same spreadsheet keep a calendar up to date automatically?
Not with the built-in import, which has no way to tell that a row it saw last week is the same row today. Re-importing the file creates a second copy of every event. Automatic updates need something that stores the created event ID alongside each row, such as an Apps Script project or a paid sync service.
Do recurring events survive a CSV import?
No. A CSV has no recurrence field, so a weekly meeting has to be written as one row per occurrence, and Google notes that such events appear as a series of one-time events rather than a repeating series. Editing the whole series later is the part that suffers, since there is no parent event to edit.