Mobile Alternative to an Excel Form: Stop Typing into Spreadsheets on a Phone

A mobile alternative to an Excel form is a web form, built around your process, that a field or warehouse team uses on their phones instead of typing into a shared spreadsheet. Fields are required, options come from controlled lists, photos attach to the record itself, and every submitted record is approved by someone else; head office sees the same records as a report. I build these apps for companies. The real problem with a spreadsheet filled in on a phone is that nobody sees the mistakes until month end. If a few records a day come in, Excel is usually enough; the sample month below shows where it stops.

In one fictional month of goods-in (receiving) inspection at a machinery manufacturer, 236 deliveries arrive from 14 suppliers. Supplier D had 5 of 18 deliveries rejected, 27.8%; the other 13 suppliers had 9 rejections in 218, 4.1%. The quality manager asks D for corrective action and tightens inspection on its next five batches. The month before, D had 4 rejections in 17 deliveries, but the shared spreadsheet showed at most 2 and spelled D’s name four ways.

This page covers operational records entered from a phone. Expense and receipt entry belongs to mobile employee expense entry, measurement tolerances and nonconformance decisions to the quality inspection records app.

What does goods-in record from a phone?

Goods-in produces two separate records from a phone: the delivery record the operative opens, and the inspection record the inspector attaches to it. Merging them into one spreadsheet row is common and starts most of the trouble: receiver and decision-maker are different people, entering at different times and places.

No inspection record opens without a delivery record: the inspector picks the batch from the bay’s list instead of retyping the delivery note number.

Indoors, GPS may not tell one bay from the next, so I suggest a QR code on each bay and the quarantine area.

Sample month: 14 suppliers, 236 deliveries

Sample data, fictional. A machinery manufacturer receives sheet metal, coated fasteners, castings and machined parts. Two operatives work the bays; inspection has three inspectors and a team leader; the quality manager and purchasing sit at head office. 20 working days; suppliers A to N.

The previous month the team typed into a shared Google Sheets file from their phones: one row per delivery, decisions in a column, photos in a WhatsApp group. Cleaning up the 228-row sheet at month end, the team leader found:

The supplier name was free text. D’s 17 deliveries appeared as “D” (7), “D Metal” (5), “D METAL LTD” (3) and “Dmetal” (2), so the monthly summary split D into four rows, none showing more than one rejection. D actually had 4 rejections; two existed only in WhatsApp.

This month the team used the app. 238 records came in; two were duplicates of the same batch by two inspectors, marked void by the team leader, leaving 236 deliveries.

During the month the form stopped or flagged:

• 33 records held before submission. 27 had no batch number, 6 had a rejection or concession with no photo. Last month’s 19 blanks became zero.
• 7 out-of-pattern values flagged. 3 decimal slips, 2 millimetre/centimetre mix-ups, 2 genuine deviations, both on D’s coating thickness.
• 41 records entered offline, in the open yard and quarantine store, sent when the signal returned.
• 4 quarantines past three working days, which reached head office as “overdue decision”.

The decision at month end

Four of D’s five rejections share one cause: coating thickness below the acceptance range. The fifth is burrs. With concessions, 8 of D’s 18 deliveries had a problem, 44.4%. The next-highest rejection rate is supplier B, 2 of 22, 9.1%.

The quality manager decided three things: D is asked, through purchasing, for written corrective action; D’s next five batches get tightened inspection for coating thickness (sample size comes from the company’s quality manual, the app only ties it to the part number); and purchasing is flagged before new orders.

Review rule (my suggestion): no coating-related rejection in the next five batches and D returns to normal inspection; two or more and purchasing evaluates an alternative supplier.

The previous month’s sheet could have produced the same decision, had the supplier come from a list and the rejection stayed in the sheet. The problem was the set-up, not Excel.

If you stay in a spreadsheet: the layout I suggest

One table, one row per delivery. Columns: A Date, B Delivery note no., C Supplier, D Part number, E Batch no., F Quantity received, G Unit, H Sample size, I Coating measurement (µm), J Decision, K Visual check, L Inspector, M Approved by, N Photo link. Columns C, D, G, J and L fill from drop-down lists on a separate list sheet, built on a desktop; their limits on a phone are covered further down.

This layout merges the delivery and inspection records into one row. That is an acceptable compromise in a spreadsheet, but the inspector has to find the operative’s row and write into it, which is where wrong-row entries come from; I suggest filtering by delivery note number.

Rejection rate per supplier:

• =COUNTIFS(C:C,"D",J:J,"Rejected")/COUNTIF(C:C,"D")

I tested the formula with a script on both months:

The wildcard gathers the four spellings but also counts any other D supplier; no formula finds the two WhatsApp rejections.

The difference an app makes, in one sentence: a defined business rule is applied while the inspector submits the record at the bay, not when someone cleans up the sheet at month end.

When is Excel, a form service or an off-the-shelf tool enough?

I would not recommend a separate app if:

• A few records a day come in and one person enters them. A protected sheet with controlled lists will do.
• Records are only collected, never approved, like visit notes. An off-the-shelf form service is usually enough.
• Your team always has a connection and photos need not be tied to the record.
• Your ERP or quality software has a mobile goods-in screen your team uses. Use that fully first.

No-code app builders and mobile form services sit in between. If your office suite includes one, try it with your own licence first and test three things: a rule-based approval chain, each role seeing only its own records, and a connection to your ERP’s supplier and order lists. Plans change often, so I name no tools or plans. If all three work, you do not need a custom app.

Form and validation rules: my starting point

These are my starting suggestions, tuned with the first month’s data. Ranges and the sampling plan come from your quality documents; the app applies them at entry.

What the form leaves out is also a decision: the gauge is selected once a day, not typed in gloves on every record.

How do offline entry and later syncing work?

Offline entry means a record made without signal waits on the phone, photos included, and is sent when the connection returns, and I suggest storing creation and arrival times separately. In the sample month 41 of 238 records were entered this way. Three consequences:

• An offline record reaches approval only when it reaches the server. Quarantine time counts from creation on the phone.
• Two records can land on one batch. It happened twice: one offline in the quarantine store, one at the bay. Both were kept; the team leader voided one.
• Unsent records can be lost with the phone. I suggest a shift does not close until the counter is zero.

Offline entry is agreed as needed in the first step, the stage where we review your process and data together and set the scope in writing. Behaviour varies by phone and browser, so it is tested on your phones first.

Who enters, who approves, and how is the audit trail kept?

The core rule I suggest: nobody approves their own record.

• Goods-in operative: opens delivery records, sees own records, requests corrections.
• Inspector: enters inspection records, proposes decisions, sees own records, requests corrections.
• Team leader: approves others’ acceptances; the quality manager approves the team leader’s own inspections.
• Quality manager: finalises rejections, concessions and corrections; changes acceptance ranges and rules.
• Purchasing: sees supplier results, cannot change decisions; maintains the supplier list.
• Management and auditors: see everything, change nothing.

I suggest everyone signs in with their own account, with no shared “bay phone password”: the core rule only works that way. Keeping purchasing out of decisions puts “accept it just once” pressure on the record.

The audit trail keeps an undeletable line per change: who, when, old and new value, reason. Two examples:

• Working day 11, one of D’s batches. The inspector typed 61 for coating thickness against a sample range of 8–12 micrometres (not a real specification). Asked to re-measure, the inspector got 6.1, below the range, confirmed it, and the batch went to the quality manager with a proposed rejection. The record carries two of the month’s seven flags, a decimal slip (61) and a genuine deviation (6.1); the 61 stays in it.
• Working day 15, another of D’s batches. The parts conformed but the label had no batch number. It was entered from the delivery note; unable to confirm it, the inspector proposed rejection, and the quality manager granted a concession against the supplier’s written confirmation. Both stay in the record.

What head office sees: deliveries, rejections, concessions and open quarantines per supplier, exportable as Excel or CSV.

What does AI do, and where does it stop?

AI here suggests; it does not decide. Range checks are the app’s own rules; a person approves. It can help in three places:

1. Category suggestions. From “rust marks on edges” the model suggests “corrosion”; the inspector picks, and causes are counted from categories.
2. Reading labels from photos, if tested. The model reads batch and part numbers from a label photo; a mismatch with the form raises a yellow warning and the inspector decides. How well it works on your labels is tested.
3. Notes on out-of-pattern values. A rule catches the value; the model adds “around ten times recent measurements, possibly a decimal slip”. The inspector corrects it.

No row goes to the model without passing the permission filter first: the model sees only records that inspector can see.

Photos and location can be personal data: a bay photo can show a number plate, location shows where the inspector worked. Under the UK and EU GDPR, personal data should be limited to what the purpose needs (GDPR, Art. 5(1)(c)). The UK regulator’s guidance on ways of monitoring workers notes that monitoring device activity can be particularly intrusive when workers use their own devices; this app does not monitor device activity, but the same proportionality applies. The ICO says the guidance is under review. My suggestions:

• no continuous location tracking; place comes from the bay QR code,
• close-up photos of part and label,
• an inspector code, not a name, sent to the model.

I do not give legal advice; I put in writing which fields go to the model, and your legal adviser assesses it.

In Turkey, sending a photo that carries personal data to an AI service abroad falls under Article 9 of KVKK (Law No. 6698), rewritten by Article 34 of Law No. 7499 with effect from 1 June 2024. I read the current text on mevzuat.gov.tr on 15 October 2026. If your company operates in Turkey, check this transfer with your legal adviser before the model sees any record.

Where exactly do Excel and Google Sheets struggle on a phone?

Both work on a phone; they struggle in how far desktop rules reach the person typing in the field. I read these help pages on 15 October 2026; versions change, so check on your phone.

• Drop-down lists. Microsoft’s Excel mobile feature table lists data validation only as “viewing” (Microsoft Support), so lists are built on a desktop. Google Sheets on Android can open a validation rule, but mobile cannot select multiple options (Google Sheets Help).
• Excel’s data form. The Form command’s help page names only desktop Excel (Microsoft Support). On a phone a record is typed cell by cell, where wrong-row entries are easiest.
• Typing at the same time. If the other person uses a supported app (Android and iOS included), their selections may show in colour; with conflicting changes the last saved change generally wins, and Microsoft suggests separate areas or sheets per person (Microsoft Support). When two inspectors write to one row, the second can change the value and no business rule checks it. More on the concurrent data entry page.
• Who changed what? Google Sheets shows cell edit history on a computer, may miss inserted rows and formula-driven changes, and sends mobile users to a computer for version history (Google Docs Editors Help); Excel’s version history also opens in the Android app (co-authoring page). Both answer “who changed it”, not “who approved it, and was that someone else”.
• Offline. In Excel on mobile, a cloud file must have been opened online at least once before going offline; pending changes sync on reconnecting (Microsoft Support). The Sheets mobile app can make one file, or recent files, available offline (Google Docs Editors Help). Either way it is set up on the phones in advance.
• Photos. Excel’s Android and iOS app turns a photo of a table into cells (Insert > Data from Picture; Image to Table in the Microsoft 365 app) (Microsoft Support). Attaching a part photo to a row as evidence is a different job.
• Google Forms and Microsoft Forms. Forms are easier on a phone, but a Google Forms file upload question requires a Google account sign-in and stores files in the owner’s Drive (Google Docs Editors Help), and Microsoft Forms allows file upload only for respondents inside your organisation (Microsoft Support). Approval has to be built separately.

When is Excel’s own Form button enough?

The desktop data form presents a worksheet row as a card and can simplify desk-based entry. It is not equivalent to a dedicated mobile field form. A Save button built with VBA also depends on desktop Excel; verify the intended device before designing the field workflow around it.

Photo uploads: accounts and storage matter

Microsoft Forms: Upload questions require an organisation-only responder setting. Do not assume an external contractor can use that version of the form. Individual-form uploads use the owner’s OneDrive; group-form uploads use the group’s SharePoint site. Checked 24 October 2026: upload requirements, storage and failure conditions.

Google Forms: Uploaders need to sign in to a Google account. Forms stored in a shared drive cannot use upload questions, and administrator data-loss-prevention settings can also restrict them. Checked 24 October 2026: Google Forms question types.

Define how each photo is tied to a delivery and found later; the file name alone may be insufficient.

Five questions before choosing a form service

1. Does every respondent have the required account?
2. Who maintains supplier and product lists?
3. Does selecting damage make a photo mandatory?
4. Where is a record stored without connectivity, and how is it sent later?
5. Who approves rejection?

A form service may suffice when accounts, lists and rules are straightforward. Test conditional requirements, offline operation and approval in the chosen tool. Photographing paper at the end of the day does not replace catching a missing field while the delivery is still present.

How do we start, who owns the data and code, and is ERP entry doubled?

In the first step we review recent weeks of the sheet; its output puts in writing the form rules, the role list, whether offline entry is needed, and the first version’s scope. The most common mistake I see in automation projects is picking the most complex process to automate first, so the first version starts at one bay with the parts that arrive most often; quarantine time and the head-office report follow, label reading and AI come last.

The app runs on a server (a VPS) that can be opened in your company’s name; records and photos are yours, exportable as Excel or CSV. There is no per-user licence; the cost is the server’s monthly fee plus maintenance, so in a small or mid-sized team adding an inspector does not change it. The source code sits in a repository you can access, with run instructions, dependencies and known limitations; because photos and location can be personal data, I assess access, security, hosting and maintenance separately.

Will goods-in be entered twice, here and in the ERP? In the first version, yes: delivery note, quantity and batch number are entered in the app too. Getting to single entry depends on whether your ERP can export its delivery list; I check that in the first step and tell you in writing. The inspection decision and the ERP stock receipt are matched on delivery note and batch number. If your ERP changes, records stay with you; only that transfer is rebuilt, and I share its scope in writing beforehand.

Send the last two weeks of your sheet, names masked, via WhatsApp on +90 549 654 64 89 or the contact page; we start from which field is most often blank.

Frequently Asked Questions

Can inspectors use their own phones, or do we need company phones?

Both work, since the app runs in the browser. With personal phones, agree who owns unsent records and how an account closes when someone leaves; I suggest keeping photos out of the gallery, tested on your devices in the first version.

Can we scan barcodes or QR codes with the phone camera?

Whether it works is tested on your real labels; it depends on print quality, code type, phone and browser, so I do not promise it beforehand. Typing always stays available.

Does the app send the rejection notice to the supplier?

Scope is set in writing in the first step. My default suggestion: a finalised rejection lands on purchasing’s list and purchasing contacts the supplier; if the app should send it, we choose the channel together.

Can a gauge send its reading straight into the form?

That depends on whether the gauge has an output a phone can reach. I do not promise it before trying; we look at its documentation together. The first version starts with manual entry.

Why can’t I use Excel’s Form button on a phone?

The desktop data form should not be assumed to exist in the mobile app. Test the entry route on the device; a browser form or custom app may be more suitable.