Published
September 30, 2026
| Updated

Nine things to prepare before onboarding procurement software

Nothing gathered before the first procurement software onboarding call, sitting beside all nine preparation items gathered in a spreadsheet without logging in.

The week between signing for procurement software and your first onboarding call is the most useful week of the whole project, and the easiest one to waste. Here is what to gather, in what order, and how good it actually needs to be.

Brandon Mead, Manager of Customer Success, Tradogram
Nothing gathered before the first procurement software onboarding call, sitting beside all nine preparation items gathered in a spreadsheet without logging in.
Take control of your procurement
Book A Demo

A gap usually exists between the day an organization signs up for procurement software and the first onboarding call. Sometimes it is a few days. Sometimes it is a few weeks, while budget clears or a finance approval works its way through.

That gap is the most valuable period of the entire project, and it is the one most teams spend waiting.

Not because anyone is disorganized. Most people assume onboarding starts when the call starts, which is a reasonable assumption, but the wrong one. What actually happens on that first call is that we ask you for your data, and everything after that depends on how quickly it arrives.

So this is the list. Nine things to gather, in an order that avoids rework, with an honest note on each one about how complete it needs to be. None of it requires the software. You can do all of it in a spreadsheet before you have even logged in.

If you would rather see the bigger picture first, how to move purchasing off spreadsheets covers what to move and in what order once your account is active. This article is about the time before that starts.

Key Takeaways

  • Preparation is the part of the onboarding process that you control completely. Configuration, training, and go-live all depend on your data arriving. Nothing else should move until it does.
  • The order the data arrives in matters more than the completeness. Four of the nine items stand alone, and five depend on something else being in place first. Gathering them out of order creates rework that feels like a software problem and isn't.
  • Good enough almost always beats complete. Active suppliers rather than every supplier, real permission groups rather than a perfect org chart. You can add to all of it later, and you will.
  • Two of the nine are optional for most teams. An item catalog only matters if you buy the same things repeatedly, and project codes only matter if you track spend by job. Skipping both is a legitimate choice, not a shortcut.
  • Your accounting system may have already done much of the work. If your vendor records are clean in QuickBooks Online, that data can transfer automatically, which changes how much of this list you actually have to build by hand.

To ensure the smoothest integration possible, start by gathering these nine things before your first onboarding call: 

  1. Your item and supplier categories
    ‍
  2. Your GL accounts
    ‍
  3. Your active suppliers
    ‍
  4. Your item catalog (if you use one)
    ‍
  5. Your locations
    ‍
  6. Your departments
    ‍
  7. Your users and their permission groups
    ‍
  8. Your projects (if you track them)
    ‍
  9. Your approval rules. 

Teams who arrive with that data ready move straight into configuration. Teams that gather it afterward can spend months on it, and the software still hasn't been touched.

Nine data sets to prepare before procurement software onboarding

If you have ever moved houses, you already know how this works. The weeks before the truck arrives are when you open the closets and the basement and decide what is actually coming with you. Nobody carries eleven years of unopened boxes into a new home and sorts them there.

Preparing your data is the same job. You are not cataloging everything your organization has ever bought. You are deciding what comes with you, and leaving the rest behind or dealing with it later, once you have somewhere to put it.

Which means the first job isn't packing. It's working out what you don't have to pack.

Start with one decision, not with a spreadsheet

Before you gather anything, find out what you will not have to gather.

If your organization runs QuickBooks Online, or another accounting system connected by API, your vendor and supplier records could transfer automatically, provided they are clean on that side. That is potentially the single largest item on this list, already done, sitting in a system somebody else in your building maintains.

It is worth ten minutes on the accounting integrations page, and one conversation with whoever owns your accounting system, before you open a blank spreadsheet. Ask them two things: 

  1. What does our vendor list actually look like in there?
    ‍
  2. How much of it is current?

Sometimes the answer is that it is immaculate and you have just saved yourself two days. Sometimes the answer is that it has eleven years of accumulated vendors in it, in which case you are better off building a short list by hand. 

Either way, knowing which one you are dealing with changes how you spend the rest of the week.

The nine things to gather before the kick-off call

This list isn't theoretical. It's the same sequence we've walked hundreds of organizations through, most of them arriving from spreadsheets and manual processes, and it exists because we watched which teams moved smoothly and which ones got stuck.

Teams who arrive with these nine things in hand spend their kick-off call on the decisions that matter: how their purchasing actually works, and what comes in by integration rather than by hand. Teams who arrive without them spend it building a task list, and the project starts from there instead.

So we structured it for you in advance. The implementation sheet has a tab for each item below, numbered the same way, with the fields already laid out so you are filling in a defined shape rather than guessing what we need. 

1. Your categories

What it is: how you group items and suppliers. Office supplies, IT hardware, facilities, professional services, and so on, with parent categories if you use them.

What to gather: category names, and which parent each one belongs under if you want a hierarchy.

How complete: rough is fine. Six to ten categories cover most organizations at the start. You can add more the first time something does not fit.

Item and supplier categories laid out with parent categories, showing a short starting list rather than a full taxonomy.

Where teams get stuck: trying to build a full taxonomy before anything else exists. Categories are a filing system, not a commitment, and the ones you invent in week one will be revised by month three regardless of how long you spend on them now.

Why it is first: supplier records refer to categories, so if you build suppliers first, you will be reassigning them afterward.

2. Your GL accounts

What it is: the general ledger accounts purchases will code to.

What to gather: account names and numbers. Export them from your accounting system rather than retyping them, so the spelling and capitalization match exactly. That matters if you integrate now or later.

How complete: fully complete, and this is one of the few that should be. It comes straight from your chart of accounts.

General ledger account names and numbers taken straight from a chart of accounts export.

Where teams get stuck: nowhere, usually, because this is not your data to produce. Send one message to your finance lead or controller asking for the chart of accounts export, and it is done. This is the fastest item on the list, and it is worth doing on day one because two other items depend on it.

3. Your suppliers

What it is: the vendors you buy from.

What to gather: company name, postal address, postal country, main contact name, and main contact email for each one. Payment terms, tax details, default currency, and bank information can follow later, and for many suppliers you will never need all of it.

How complete: active suppliers only. The ones you have actually bought from in the last ninety days or so, which you can usually reconstruct from recent invoices without asking anybody. Add the rest as they come up.

Supplier records with only name, address, and contact details completed, and payment and banking columns left empty for later.

If you do not have a contact name or email for a supplier, use a placeholder such as "Sales" rather than stopping to chase it. You can fill it in properly later, and you will want a real email on at least one contact before you send that supplier a purchase order. But a missing contact name should never be the reason a file does not get uploaded. 

Where teams get stuck: this is the single most common stalling point in the whole process, and it is worth naming plainly. Someone decides they need a complete, reconciled, deduplicated supplier list before anything can begin. Three departments each have their own version, a third of the entries are inactive, and two months later nothing has gone live.

A short accurate list beats a long stale one. A list full of vendors nobody has used since 2019 is a list your team will stop trusting, and untrusted data is worse than incomplete data.

Where it sits: your categories need to exist first, and your item catalog depends on this. 

4. Your items

What it is: the things you buy repeatedly, as a catalog.

What to gather: item name, unit of measure and unit amount, and optionally a description, price, category, GL account, and default supplier.

How complete: skip it entirely if you do not buy the same things on a repeating basis. Many organizations never build an item catalog and run perfectly well without one, entering items as free text on each request.

An item catalog with unit of measure, category, and supplier assigned, marked as optional for teams that do not buy repeat items.

Where teams get stuck: building a catalog because it is on the list rather than because they need one. This item depends on categories, GL accounts, and suppliers all being in place, which makes it the most expensive one to do early and the easiest one to defer. If you are unsure, defer it.

5. Your locations

What it is: your branches, sites, offices, plants, or warehouses, and their addresses.

What to gather: branch name, street address, country, default currency, and time zone. Also note which addresses are used for delivery, billing, and distribution, since those are often not the same.

How complete: complete, but low effort. Single-location organizations finish this in about a minute.

Two company locations with delivery, billing, and distribution addresses marked separately.

Where teams get stuck: multi-location teams sometimes discover they have never written down which site bills where. That is a useful thing to find out now rather than when the first invoice goes to the wrong office.

6. Your departments

What it is: the teams that request and own spend.

What to gather: department name, the location it belongs to, who manages it, and which categories and GL accounts it uses.

How complete: the departments that actually buy things. If a team has never raised a purchase request in its life, it does not need to be here on day one.

Departments mapped to locations, managers, and GL accounts, with one department covering multiple accounts.

Where teams get stuck: this is where your organization chart meets your chart of accounts, and they do not always agree. Marketing might be one department to HR and three cost centers to finance. Decide which version you are using here before you configure anything, because departments drive both budget control and approval routing later.

Assigning a department manager is optional, but it is worth doing, because that person gets notified when a requisition is raised for their department. 

7. Your users

What it is: the people who will log in, and what each of them is allowed to do.

What to gather: name, email, main location, and permission group. Also their department, and any additional locations they work across.

How complete: everyone who will touch a purchase in the first stage. You do not need to onboard the whole company at once, and in most cases you should not.

Users assigned to permission groups including requisitioner, approver, and purchaser, with a short description of each group.

On permission groups: most people fall into one group. Requisitioner covers people who only raise requests. Approver covers people who only approve. Purchaser covers the buying team. Receiver, accounts payable, auditor, and administrator roles do what their names suggest.

Assigning a group overrides whatever permissions that user had before, so it is worth deciding the group deliberately rather than adjusting individual permissions later and having a role change undo them. 

Where teams get stuck: giving everybody administrator access because it seems simpler. It is simpler for about three weeks, and then nobody knows who changed a supplier record. Start narrow. Widening someone's access takes ten seconds and is a much easier conversation than the alternative.

8. Your projects

What it is: the jobs, projects, or cost centers you track spend against, if you do.

What to gather: project name, number, budget amount and currency, and project lines if you break budgets down further.

How complete: skip it if you code spend to departments rather than projects. Construction, engineering, and professional services teams usually need this. Most others do not.

Project records with budget amounts and project lines, marked as optional for teams that code spend to departments.

Where teams get stuck: nowhere, if they skip it. This is a foundation layer that can be added later without disturbing anything already built, which makes it a safe deferral.

9. Your approval rules

What it is: who approves what, under what conditions.

What to gather: for each rule, the required fields are transaction type, hierarchy level (from one to ten), approver name, and at least one criterion, which can be amount, department, category, or project. Also add alternates for when someone is away.

How complete: this is the one item where thinking matters more than data entry. Write down the rules you actually want, not the rules you currently have, because the current ones probably live in people's heads.

Two approval rules set by amount threshold and department, the higher one adding a second approver and an alternate.

Where teams get stuck: discovering that the real policy and the written policy are different. Somebody will say that purchases over $5,000 need the CFO, and somebody else will say that stopped being true last year. 

This is genuinely good news, because it is far cheaper to resolve on paper than in production, but it does take a conversation, and it is worth scheduling that conversation rather than hoping it happens.

Start simple. Amount thresholds plus department covers most organizations completely, and you can layer in category, project, GL account, or supplier conditions once the basic routing is working.

Why it is last: approval rules refer to almost everything else on this list. Your departments, locations, users, categories, and GL accounts all appear in them, which is why writing them before those exist means rewriting them afterward.

Why the order matters

Four of these stand alone. You can build them in any order, on any day, without waiting for anything.

The other five refer to something above them, and that is where rework comes from. Nobody notices at the time. You build a supplier list, then build categories, then spend an afternoon reassigning every supplier to a category that did not exist when you entered it.

Item Depends on
Categories Nothing
GL accounts Nothing
Locations Nothing
Projects Nothing
Suppliers Categories
Items Categories, GL accounts, suppliers
Departments Categories, GL accounts, locations
Users Locations, departments
Approval rules Nearly everything above

The practical reading of that table: do the four that depend on nothing first, ideally in parallel, since they involve different people. GL accounts come from finance. Locations come from operations. Categories and projects come from you. Then build suppliers, then departments and users together, and write your approval rules last.

How complete does this actually need to be?

Complete enough to go live, not complete enough to be finished. Those are different targets, and only one of them is reachable this month.

That is a genuinely uncomfortable instruction for the kind of person who usually ends up owning this project, because the people who take on a procurement rollout are frequently the same people who like things tidy. The instinct to get it right before showing anyone is a good instinct, but it works against you here.

With a short, accurate data set, a workflow goes live, people start using it, and the gaps reveal themselves in the normal course of work. 

  • A supplier is missing, so somebody adds it. 
    ‍
  • A category does not fit, so you create one. 

That is a five-minute task inside a working system, and it is much easier than predicting every gap in advance from a blank spreadsheet.

What usually happens with a long, perfect data set is that it takes months, during which nothing is live, nobody is using anything, and the people who were enthusiastic in January have stopped asking about it.

Aim to have the nine items in a usable state within a week or two. Teams who hit that mark tend to move straight into configuration and training with real momentum.

It is not a deadline anybody imposes on you, and nothing bad happens if you miss it, but it is a target worth setting because the alternative is open-ended.

What happens after you send the spreadsheet

Your Customer Success contact reviews the data and comes back on anything that looks incomplete or inconsistent before it goes near the system. That review is a normal part of the process rather than a test, and gaps found there are much easier to fix than gaps found later.

Once the data is confirmed, migration runs on a one- to two-day turnaround. Then configuration starts: your approval rules get built, your forms get set up, and your training is planned around how your organization actually buys, not a generic walkthrough.

That is the asymmetry worth noticing. The gathering is the part that takes a week, and it is yours. Everything after it moves in days, and all of it is blocked until the data arrives. Which is why the week before your kick-off call is worth more than any week after it.

Two things you can do this afternoon

Send one message to your finance lead asking for your chart of accounts, and open your last three months of invoices to pull out the suppliers that appear. Those two tasks take an afternoon between them and cover the two items most likely to slow you down.

Everything else on the list is either small, optional, or a conversation you were going to need to have anyway. None of it requires a login, a meeting, or anybody's permission.

When you are ready to think about what moves into the system first, and what can stay in your spreadsheet for now, the staged approach to moving off spreadsheets picks up where this leaves off.

Explore Tradogram's procurement features to see what your team will be working in once the data is ready.

Frequently Asked Questions

What if we do not have some of this data?

Then you do not need it yet, in most cases. Item catalogs and project codes are genuinely optional, and plenty of organizations never build either. If something more fundamental is missing, such as a documented approval policy, that is worth treating as a finding rather than a blocker. You were going to have to decide it eventually, and deciding it now costs a conversation rather than a rebuild.

Who should own this internally?

One person, with the authority to make decisions rather than only to collect files. Most of the delay in gathering this data comes from waiting on other people, and a coordinator who has to ask permission for every answer will wait longer than one who can decide. Finance owns the chart of accounts, operations usually owns locations, and whoever runs purchasing owns the rest.

Do we have to stop using our spreadsheet while we prepare?

No, and you should not. Nothing changes about how you buy things until your first workflow goes live. Preparing this data runs alongside business as usual, and the spreadsheet stays exactly where it is until something better replaces it.

How detailed should our approval rules be at the start?

Less detailed than you think. Amount thresholds plus department handles most organizations, and a rule set simple enough that people can explain it out loud is a rule set that gets followed. You can add conditions for category, project, location, or supplier once the basic routing is running and you can see where it needs refining.

Written by:

Brandon Mead, Manager of Customer Success, Tradogram
Manager of Customer Success, Tradogram

Brandon Mead is the Manager of Customer Success at Tradogram, where he oversees global customer success and onboarding programs and works with organizations across a wide range of industries. His background includes implementing software solutions and customer engagement strategies in both established technology companies and startup environments, including work connected with HubSpot and Jobber.

Take control of your procurement with Tradogram

Tradogram requisition dashboard showing an approval workflow Book A Demo