AWRA OpsHub Search
Bulk import & data onboarding

Your data is already in a spreadsheet. That is not the problem — it is the starting point.

Every operations rollout stalls in the same place: eleven hundred items in a workbook somebody has maintained for six years, and no obvious way to get them into the new system without a consultant and a fortnight. Thirteen templates, in the exact column order the loader expects, with a filled example row and the required columns starred — download, paste, upload.

Start free See all thirteen templates
awra-items-template.xlsx — Items
ABCDEF
Name* Inventory Account* Category Stock Reorder Point Barcode
1 Sample ItemInventory AssetGeneral103SKU-001
2 Diesel filter kitInventory AssetSpares8420SKU-2210
3 Latex gloves, boxInventory AssetConsumables24060SKU-2211
4 Angle grinder discStock AcctSpares3612SKU-2212
5 Inventory AssetSpares186SKU-2213
2 rows rejected, 3 imported. Row 4: “Stock Acct” matches no account in your chart. Row 5: Name is required and is empty. The other three are in. Nothing is rolled back for a bad row, and nothing is guessed at for one either.

Why rollouts stall here

The expensive part of data migration is not the typing. It is the arguing about shape.

Somebody sends a workbook. It has a column called Qty that sometimes holds a number and sometimes holds “approx 40”. It has three columns that all appear to be a category. It has a location column with fourteen distinct spellings of the same store. Nobody can start loading it until those questions are answered, and answering them takes three meetings because the people who know are on site.

A template does not solve the data quality problem. What it does is fix the shape before the argument starts — here are the columns, in this order, these two are required, and this is what a correct row looks like. That turns three meetings into a filled-in file, and it is the reason all thirteen templates ship with a real example row rather than an empty grid.

Every template downloads filled in

Not a blank header row. A worked sample line with plausible values — an item called Sample Item with an inventory account, a category, a stock figure, a reorder point and a barcode — so the shape of a correct row is visible rather than described.

  • Required columns carry a marker in the first row, so nobody has to read documentation to know what is mandatory.
  • Notes on the sheet name the allowed values — the adjustment types, the custodian types, the account types — rather than leaving them to be discovered by rejection.

Column headings are matched, not counted

The loader reads the first row as headings and normalises them, so an extra column your team added, a different order, or inconsistent casing does not derail the file. What it will not do is guess which of your columns was meant to be the name.

  • A file whose first row is not headings is rejected with that as the reason, rather than importing the headings as a record.
  • Entirely blank rows are skipped rather than counted as failures, because every real workbook has them.

CSV, XLSX or XLS

Whatever the workbook already is. The parser reads the first sheet and closes the file properly afterwards, which matters more than it sounds when somebody uploads a forty-thousand-row spreadsheet from a laptop on a hotel connection.

  • Uploads above roughly a quarter of a megabyte are handed to a background job instead of running in the request.
  • Small files import immediately, so a fifty-row correction does not go into a queue and make you wait.

All thirteen, with the honest column

Thirteen templates. Eight of them load rows. The table says which.

This is the part most vendors round up, and it is the part a prospect finds out about on day three. So it is a column in the table rather than a footnote: Loads rows means you upload the file and the records appear. Shapes the data means the template downloads with the right columns, order, required markers and example row — genuinely useful for getting a workbook into a state anybody can work with — and the rows are then brought in through the module's own screens or its API rather than by uploading the file back.

TemplateColumnsRequiredStatus
Master data — start here
Warehouses Name, Code, Address, Manager Email, Status

Name, Code

 Loads rows
Locations Warehouse Code, Name, Code, Capacity

Warehouse Code, Name, Code

 Loads rows
Chart of Accounts Account Name, System Key, Account Type, Normal Balance, Description

Account Name, Account Type, Normal Balance

 Loads rows
Vendors Name, Email, Phone, Country, Company, Address, Latitude, Longitude

Name, Email

 Loads rows
Customers Company Name, First Name, Last Name, Email, Phone, Country, Address, Currency Code, Credit Limit, Status, Notes

Company Name

 Loads rows
Things you hold
Items Name, Inventory Account, Category, Description, Stock, Reorder Point, Buying Price, Markup (%), Barcode

Name, Inventory Account

 Loads rows
Assets Asset Code, Name, Barcode, Asset Type, Tracking Mode, Pool Quantity, Category, Serial Number, Model, Manufacturer, Purchase Date, Purchase Cost, Currency, Ownership Type, Condition, Status, Risk Level, Warehouse Code, Location Code, Custodian Code, Notes

Name, Asset Type, Tracking Mode

 Loads rows
Asset Custodians Custodian Code, Employee Number, Name, Email, Phone, Custodian Type, Status, Job Title, Department, Warehouse Code, Location Code, External Reference, Notes

Name, Custodian Type

 Loads rows
Movement & transactions
Stock Adjustments Adjustment Type, Item Barcode, Item Name, Warehouse Code, Location Code, Quantity, Reason, Occurred At, Reference, Notes

Adjustment Type, Item Name, Warehouse Code, Location Code, Quantity

 Shapes the data
Stock Transfers Transfer Number, Item Barcode, Item Name, From Warehouse Code, From Location Code, To Warehouse Code, To Location Code, Quantity, Requested Date, Notes

Item Name, From Warehouse Code, To Warehouse Code, Quantity

 Shapes the data
Procurement Request Lines Request Title, Department, Item Name, Item Barcode, Description, Quantity, Estimated Unit Price, Required Date, Priority, Justification

Request Title, Item Name, Quantity

 Shapes the data
RFQ Lines RFQ Title, Item Name, Item Barcode, Description, Quantity, Unit, Target Delivery Date, Specification Notes

RFQ Title, Item Name, Quantity

 Shapes the data
Opening Balances Account Name, System Key, Opening Debit, Opening Credit, Balance Date, Reference, Notes

Account Name, Balance Date

 Shapes the data

There is a pattern in that split, and it is not an accident. The eight that load are master data — things that exist. The five that shape are movements and balances — things that happened, and which therefore have to hit stock ledgers, approval states, journal lines and period boundaries on the way in. Loading a warehouse wrong gives you a warehouse with a typo. Loading a stock adjustment wrong gives you a stock figure that disagrees with the shelf and a journal entry nobody can trace. We would rather those went through the module that understands them.

Order matters

Five files, in this order, and your workspace has a spine.

The templates reference each other by code, so the sequence is not a suggestion. An asset that names a warehouse code needs that warehouse to exist; a location that names a warehouse code needs the same. Get the order right and every file lands cleanly. Get it wrong and you spend an afternoon on rejections that were entirely avoidable.

Chart of Accounts

Because Items requires an inventory account by name, and an item row naming an account that does not exist is the single most common rejection in a first import. Load your accounts and the item file stops arguing.

Account Name → referenced by Items

Warehouses

Codes here become the anchor for everything physical. Use short, stable codes — MAIN, BR1, KIS — because four other templates reference them and renaming one afterwards means editing four files.

Code → referenced by Locations, Assets, Custodians

Locations

Bins, shelves, zones. Each row names its warehouse by code, so this file cannot run before the warehouses file. Capacity is optional and worth filling in if you intend to use slotting.

Warehouse Code → must already exist

Asset Custodians

The people and departments who hold things. Loaded before assets so that an asset row can name its custodian by code and arrive already assigned, rather than arriving unassigned and needing a second pass.

Custodian Code → referenced by Assets

Items, Assets, Vendors, Customers

The four big master files, in any order among themselves. Items needs the accounts; Assets can name a warehouse, a location and a custodian, all of which now exist. Vendors and Customers stand alone and can go first if you prefer.

All references resolved by now

How the files join up

Codes, not internal identifiers. That is what makes a spreadsheet migration possible at all.

The reason most import features are unusable is that they want database identifiers you do not have. These templates join on codes you choose — a warehouse code, a location code, a custodian code, an account name — so a file can reference a record that was created by another file, and both files were written by somebody with no access to the database.

Warehouses.xlsx Code = MAIN Locations.xlsx Warehouse Code = MAIN Custodians.xlsx Custodian Code = EMP-001 Chart of Accounts.xlsx Inventory Asset Assets.xlsx Warehouse Code MAIN Location Code SHELF-A Custodian Code EMP-001 Items.xlsx Inventory Account

One rule to get right, and it is the codes.

Pick short, stable, human codes before you start, and write them the same way in every file. The templates say so on the sheet — the warehouse template's own note is that the codes should be stable because other templates reference them. That single sentence saves more time than any other line in the feature.

The corollary is a genuine warning: a code you change later does not update the files that referenced it. If you rename MAIN to NRB-01 after loading assets, the asset file you keep as your record no longer describes what is in the system. Decide the codes once, with the person who runs the store in the room.

Read the migration guide

Small file, large file

A fifty-row correction and an eleven-thousand-row migration should not behave the same way.

Most import features pick one behaviour and make everybody live with it. Either everything runs in the request — and a large file times out halfway through — or everything goes into a queue, and a five-row fix leaves you refreshing a page. The size of the upload decides, at roughly a quarter of a megabyte, and the logic on both sides is the same code.

Under ~256 KB

Imported in the request, result on screen

You upload, and the outcome is in front of you: how many rows went in, which ones did not, and why. For the corrections and small additions that make up most real-world use, waiting for a queue would be a worse experience than the import itself.

Above ~256 KB

Handed to a background job

The file is taken, the job is queued, and you get on with something else. Crucially it is the same import logic running — the parsing, the validation and the record creation are one implementation, deliberately written to take its workspace and user context as arguments rather than reading them from the request, precisely so it can run outside one without behaving differently.

Rows are independent. A bad row is reported and skipped; the good rows around it are created. That is the right trade for a migration: an eleven-thousand-row file with forty problems should give you eleven thousand and forty records less forty, plus a list of forty things to fix — not a rollback and a fortnight of bisecting a spreadsheet to find the offending line.

Three more importers, with their own flows

Where the data is sensitive enough to deserve a preview before it commits.

Three imports sit outside the general template machinery because they need a step it does not have: you see exactly what would be created, and then decide. That is the right shape when a mistake means somebody is paid wrongly or an attendance record is wrong for a month.

Employees

Its own template, its own form, and a two-stage flow: upload to preview, read what would happen, then commit. Employee records carry pay, statutory identifiers and contract history, so a silent partial import is not an acceptable outcome.

  • Preview and commit are separate steps with separate routes.
  • Template downloadable from the same screen as the upload.

Attendance

The same preview-then-commit shape, for bringing in clock records from a biometric device, a legacy system or a period somebody kept on paper. Attendance feeds payroll, so seeing the rows before they land is the difference between a correction and a payroll rerun.

  • Bulk backfill for a historical period, rather than day-by-day entry.
  • Its own template with the columns the parser expects.

Vendor quotations

A supplier sends a priced spreadsheet against your RFQ. Rather than retyping thirty lines into a comparison screen — with the transcription errors that guarantees — the quotation is imported against the RFQ it answers.

  • Keeps the supplier's own figures rather than a keyed copy of them.
  • Lands in the quotation comparison alongside the others.

And one that is not a data import at all but behaves like one: workflow definitions can be imported, so a rule set built and proven in one workspace can be carried into another rather than rebuilt from a screenshot.

The straight answer

Read this before you plan a migration around it.

Import is where software marketing is least reliable, because the demo is always five clean rows. Here is the real shape of it.

Bulk import — what is real

What AWRA OpsHub does today

  • Thirteen downloadable templates, each with the exact columns in the exact order, required columns marked in the first row, a worked example row filled in, and notes naming the allowed values for constrained fields.
  • Eight of them load rows directly: warehouses, locations, chart of accounts, vendors, customers, items, assets and asset custodians — the master data that has to exist before anything else can reference it.
  • Cross-file references by human codes rather than database identifiers — warehouse code, location code, custodian code, account name — so a file written by somebody with no database access can reference records created by another file.
  • CSV, XLSX and XLS all accepted, with the first sheet read and headings normalised, so an extra column, a different order or inconsistent casing does not derail the upload.
  • Row-level independence: a bad row is reported and skipped and the good rows around it are created, which is the right trade for a large migration.
  • Structural problems reported as themselves — a file whose first row is not headings is refused with that as the reason, rather than importing the headings as a record.
  • Large uploads processed in the background above roughly 256 KB, with small ones imported in the request so a fifty-row correction is not queued, and the same import logic on both paths.
  • Employee and attendance imports with a preview-then-commit flow, because a wrong row there means somebody is paid incorrectly.
  • Vendor quotation import against an RFQ, so a supplier's priced spreadsheet becomes a quotation without thirty lines of retyping.
  • Workflow definition import, so a proven rule set can be carried between workspaces rather than rebuilt from a screenshot.
  • Custom fields populated by import, so your own attributes come in with the record rather than needing a second pass.

More we can add to your workspace

  • Row loading for the five movement and balance templates — stock adjustments, stock transfers, procurement request lines, RFQ lines and opening balances — with the stock-ledger, approval-state, journal and period rules that would have to govern them.
  • An interactive column mapper, so a workbook can be uploaded in whatever shape it already has and the columns matched on screen instead of rearranged in Excel first.
  • A dry run for the general templates, of the kind employee and attendance import already have — see exactly what would be created, then commit.
  • Update-and-match on import, so a second upload of the same file corrects existing records by code instead of only creating new ones.
  • A downloadable rejection file, with the failed rows and their reasons in the same shape as the original so they can be fixed and re-uploaded directly.
  • Deduplication across an upload — catching two spellings of the same vendor within one file before both are created.
  • Templates for the remaining modules — projects, tasks, tickets, expenses and budget lines.
  • Direct migration connectors that read from a named legacy system rather than from a spreadsheet exported out of it.

Where we point you to a specialist

  • We will not import a stock movement or an opening balance from a spreadsheet today, and we will not pretend those templates do. A wrong warehouse gives you a warehouse with a typo. A wrong adjustment gives you a stock figure that disagrees with the shelf and a journal entry nobody can trace. Those five templates shape the data; the rows go in through the module that understands the ledger, and the table on this page says so in its own column.
  • We will not guess which of your columns was meant to be the name. Headings are matched and normalised, not inferred. A silent mis-mapping across eleven thousand rows is the single most expensive failure this feature could have, and a rejection you can read is cheaper than a success you cannot trust.
  • We will not roll back a whole file for one bad row. That is a deliberate trade, and it goes the other way for the sensitive imports: employees and attendance get a preview and a commit precisely because there the all-or-nothing behaviour is the correct one.
  • We will not clean your data for you. Fourteen spellings of one store name are a decision somebody in your organisation has to make, and a vendor who silently picks one has made it for you — badly, and invisibly.

An interactive column mapper and a downloadable rejection file are the two items in that middle column that most change a large migration, and both are small next to the loaders that already exist. Row loading for the movement templates is the bigger conversation, because the honest part of it is your stock and period rules rather than the parser. Tell us what shape your existing data is actually in and we will come back with a written spec, a timeline and a price.

Before and after the import

Loading the data is the middle of the job.

Migration Guide

The practical sequence for moving off spreadsheets or another system, written as a plan rather than a feature list.

Open

Item Master Governance

What happens after the items are in: duplicate detection, barcode collisions and a second approver on the fields that matter.

Open

Departments, Locations & Reason Codes

The coding dimensions your imported records get filed against, and why deciding them first pays for itself.

Open

Asset Custodians & Custody Chain

The custodian codes the asset template references, and what custody means once the register is loaded.

Open

Field Customization

Your own fields on standard records — populated by the same import rather than by a second pass.

Open

Implementation Services

When the data is messy enough that you would rather somebody did this with you.

Open

What changes

Go-live stops being a project and becomes an afternoon.

Not because the data got cleaner, but because the shape stopped being negotiable. Five files in a known order, codes decided once, rejections you can read and fix. Most organisations do this themselves in a day.

Get started free Ask about your data

No consultant for master data

Eight loaders covering warehouses, locations, accounts, vendors, customers, items, assets and custodians.

The shape argument ends early

Thirteen templates with the columns, the order, the required markers and a worked example row.

Files reference each other

Codes you choose, not identifiers you do not have, so one file can build on another.

A bad row costs you a row

Skipped, reported with a reason, and the eleven thousand good ones are already in.

Large files do not time out

Above a quarter of a megabyte it goes to a background job, running the same logic.

Payroll data gets a preview

Employees and attendance show you what would be created before anything commits.

Frequently asked questions

How many import templates are there, and do they all load data?
Thirteen templates download; eight of them load rows directly. The eight are warehouses, locations, chart of accounts, vendors, customers, items, assets and asset custodians — the master data that other records reference. The other five — stock adjustments, stock transfers, procurement request lines, RFQ lines and opening balances — download with the correct columns, order, required markers and a worked example, which fixes the shape of the data, but the rows are brought in through the module that owns them rather than by uploading the file back. That split is stated in a column on the template table rather than hidden in a footnote, because it is the thing a prospect otherwise discovers on day three.
Why can I not import stock movements from a spreadsheet?
Because of what a wrong row costs. A mistyped warehouse gives you a warehouse with a typo, which somebody notices and fixes. A mistyped stock adjustment gives you a stock figure that disagrees with the shelf, a journal entry nobody can trace, and possibly a period that no longer balances — and it does all of that silently. Movements and balances have to hit stock ledgers, approval states, journal lines and period boundaries on the way in, and we would rather those went through the module that understands those rules. The template still earns its place: it gets the data into a shape anybody can work with.
What order should I load the files in?
Chart of accounts first, because items require an inventory account by name and an item row naming a non-existent account is the most common first-import rejection. Then warehouses, whose codes anchor everything physical. Then locations, which name their warehouse by code. Then asset custodians, so assets can arrive already assigned. Then items, assets, vendors and customers in any order among themselves. Get the sequence right and every file lands cleanly; get it wrong and you spend an afternoon on avoidable rejections.
How do the files reference each other?
By human codes you choose, not by database identifiers you do not have — a warehouse code, a location code, a custodian code, an account name. That is the design decision that makes a spreadsheet migration possible at all: a file written by somebody with no database access can reference records created by another file. The corollary is a real warning, and the templates say so on the sheet: pick short, stable codes before you start, because renaming one later does not update the files that referenced it.
What happens to rows that fail validation?
They are reported and skipped, and the good rows around them are created. An eleven-thousand-row file with forty problems gives you eleven thousand records less forty, plus a list of forty things to fix — rather than a rollback and a fortnight spent bisecting a spreadsheet. Entirely blank rows are skipped without being counted as failures, because every real workbook has them. A structural problem is reported as itself: a file whose first row is not headings is refused for that reason rather than importing the headings as a record.
Is there a size limit, and will a large file time out?
The size decides the path rather than causing a failure. Uploads above roughly 256 KB are handed to a background job; smaller ones are imported in the request so that a fifty-row correction shows you its result immediately rather than going into a queue. Both paths run the same import logic — it takes its workspace and user context as arguments rather than reading them from the request, specifically so it behaves identically inside and outside an HTTP request.
Are CSV files supported, or only Excel?
CSV, XLSX and XLS all work. The first sheet is read and the column headings are normalised, so an extra column your team added, a different column order, or inconsistent casing does not derail the upload. What the loader will not do is guess which of your columns was meant to be the name — headings are matched, not inferred, because a silent mis-mapping across eleven thousand rows is the most expensive failure this feature could have.
Are there imports for employees, attendance or supplier quotations?
Yes, and all three sit outside the general template machinery because they need a step it does not have. Employee and attendance imports run preview-then-commit: you upload, see exactly what would be created, and then decide — appropriate where a wrong row means somebody is paid incorrectly or a month of attendance is wrong. Vendor quotations can be imported against the RFQ they answer, so a supplier's priced spreadsheet becomes a quotation without thirty lines of retyping and the transcription errors that guarantees. Separately, workflow definitions can be imported, so a proven rule set can be carried between workspaces rather than rebuilt from a screenshot.

Help Center

Need a quick answer while you read?

Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.

Search all approved AWRA public help articles.

Open Help Center