ERP Interview Questions
ERP interviews test domain understanding and practical judgement, not algorithms. Here’s what gets asked, with the answers that demonstrate depth.
Domain fundamentals
Q: Walk me through what happens in the system when goods are received against a purchase order.
A strong answer covers:
- A material document is created with movement type 101
- Stock quantity increases in the receiving plant/storage location
- If quality inspection is required, stock goes to inspection stock, not unrestricted
- Accounting: Inventory Dr (at valuation price), GR/IR clearing Cr (at PO price).
If the material uses standard costing and the PO price differs, the difference
posts to a price variance account
- The PO line's open quantity reduces
- Document flow links PO → material document
- Batch and serial numbers are captured if the material requires them
- The warehouse may generate a put-away task
- The invoice can now be three-way matched
The GR/IR explanation is the key differentiator. If you can explain why GR/IR exists — the timing gap between physical receipt and the supplier’s invoice, and the need for both inventory and liability to be correct at period end — you’re demonstrating real understanding.
Q: Why can’t you just delete a posted invoice?
- Financial records are legally immutable; auditors must reconstruct the books
as of any past date
- Document numbering must be gapless in most jurisdictions; a gap looks like
suppressed revenue
- Downstream systems and the tax authority may already have the document
- The correct mechanism is a reversal or credit memo, which is itself a document,
linked to the original, leaving both visible forever
- The audit trail must show that a mistake was made AND corrected
Q: What’s the difference between document date and posting date?
Document date = the date on the physical document (the supplier's invoice date).
Drives payment terms and the tax point.
Posting date = which accounting period this hits. Drives period, exchange rate,
and reporting.
Entry date = when it was typed in. Audit trail only.
You can enter an invoice on 5 February, dated 28 January, with a posting date of
31 January, if period 1 is still open. All three are different and all correct.
Q: A user says the system posted to the wrong GL account. Where do you look?
Not the code — the account determination configuration.
- Which determination table applies (movement type + valuation class,
or condition type + account key, or asset class, etc.)
- What the material's valuation class is
- Whether the right document type / transaction key was used
- Whether the master data has changed since the posting
95% of "wrong account" issues are configuration or master data, not code.
Q: Explain FIFO vs moving average vs standard cost.
Answer with the mechanics and the business implication:
FIFO — oldest cost consumed first. Layer tracking. IFRS default.
Moving average — one blended cost, recalculated on each receipt. Simple, common,
but dangerous with low stock quantities (a small absolute
difference on 0.1 units produces a wild unit price)
Standard cost — planned cost, differences go to variance accounts. Makes
variances visible and analysable. Dominant in manufacturing.
Requires an annual roll-up that revalues all inventory.
LIFO — permitted under US GAAP, prohibited under IFRS.
Technical
Q: How would you design an interface that receives sales orders from an e-commerce platform?
They want to hear about failure modes, not the happy path.
- Asynchronous: accept, queue, process — never block order creation on
the ERP being available
- Idempotency key derived from the store's order ID, not a generated UUID,
so retries don't duplicate
- Error classification: transient (retry with backoff), validation (dead letter,
notify), business (dead letter with a readable reason)
- Dead letter queue with an owner and an alert
- Cross-reference table mapping store IDs to ERP IDs
- Daily reconciliation: orders received vs orders created, with values
- Volume tested at peak (Black Friday, campaign launches)
- Defined behaviour when the store is down and when the ERP is down
Q: A month-end batch job takes 6 hours and the window is 4. What do you do?
1. Measure first — where is the time actually going?
2. Check for N+1 patterns and per-record queries
3. Check indexes and execution plans on the heavy queries
4. Parallelise by a natural key range (company, plant, asset number)
5. Chunk commits rather than one giant transaction
6. Pre-aggregate what's re-derived repeatedly
7. Bound the selection — is it processing more data than it needs?
8. Check for contention with other jobs running concurrently
9. Only then: consider more hardware
Q: How do you prevent two sales orders confirming the same stock?
Four legitimate strategies, and it's a business decision, not just technical:
- Lock the material/plant for check+confirm: correct, bottleneck on hot items
- Optimistic: re-check at save, fail if over-committed
- Reservation: the check creates a short-lived hold that converts or expires
- Accept over-commitment and resolve in backorder processing
The question is: is occasionally disappointing a customer worse than slowing
order entry for everyone? High-value low-volume favours locking; fast-moving
consumer goods usually accept over-commitment.
Q: Why is idempotency important in ERP integration?
Networks time out. The caller doesn't know whether the posting succeeded, so it
retries. Without idempotency you post the invoice twice — which is a real
financial event, not a duplicate row.
The key must be derived from the business event (source system + document + line),
not generated per attempt, or a retry produces a new key and defeats the mechanism.
Better still: a unique constraint on the natural business key
(company, vendor, invoice_number) — the database refuses the duplicate,
and it also catches human double-entry.
Design and judgement
Q: The business wants a custom field on the sales order. What do you do?
1. Check whether a standard field already means that (there are usually
unused "customer group 1–5" style fields)
2. Understand what it's for — is it reporting, process control, or output?
3. Decide the level: header, item, or an org-level view?
4. Use the sanctioned extension mechanism, not a bolt-on table
5. Add it everywhere: table, screen, API, search help, migration template,
print form, reports. A half-added field is permanently empty
6. Document it in the data dictionary
Q: A requirement will take 30 days to build. How do you approach it?
"If we build this, it costs 30 days now plus retesting at every upgrade forever.
Here are three alternatives:
- Configuration X gets us 80% of the way for 2 days
- The standard process does it differently but acceptably
- We defer to phase 2 and see if it's still needed
If none of those work and it's a legal requirement, we build it — and I'll
register it with an owner and a review date."
Then build it if they confirm. The point is to make the cost visible and let
the business decide, not to refuse.
Q: How would you approach a data migration?
1. Profile first — how much data, how bad is it? (This usually reveals that
47,000 "customers" are actually 6,000 active ones plus 41,000 of debris)
2. Scope: master data and open items only. History stays in legacy or an archive
3. Cleanse in the SOURCE system, with named business owners
4. Map every field explicitly — including derived and constant values,
which is where most defects hide
5. Validate before loading, never during
6. Load via vendor tools or APIs, never direct table inserts
7. Load in dependency order; GL opening balances last
8. Reconcile counts AND values after every object; business owner signs off
9. Four rehearsals minimum, timed
10. Keep the legacy-to-new ID cross-reference forever
Behavioural
Q: Tell me about a time a requirement didn’t make sense.
They want: did you push back constructively, or just build it? A good answer describes asking why, discovering the underlying need was different, and delivering something better — or delivering what was asked with the concern documented.
Q: How do you explain a technical constraint to a non-technical stakeholder?
Use an example. “The finance team wanted real-time inventory valuation on the dashboard. I explained that recalculating it live would slow order entry for everyone, showed them the numbers, and proposed a five-minute refresh instead. They agreed immediately once they understood the trade-off.”
Q: What happens when you’re on call during month-end close and something breaks?
They want to hear: calm, prioritisation, communication, and knowing the difference between “the close is blocked” and “a report looks odd”. Also: do you know what a close is?
Questions YOU should ask
Good questions signal experience:
- What deployment model, and what's the upgrade cadence?
- How many custom objects are there? How many core modifications?
- What's the ratio of support to project work in this role?
- How does code get to production? Who deploys?
- Do developers have production access? (The right answer is no)
- What does the close process look like, and is the team on call for it?
- Is there an automated regression suite?
- How mature is the data quality? Who owns master data?
- What's the biggest technical debt item?
- How are requirements challenged before they become development?
Asking “how many core modifications do you have?” tells the interviewer you understand the customisation tax. It’s one of the strongest signals you can send in an ERP interview.
Red flags in their answers
If you hear these, weigh them:
"We customised heavily because our processes are unique" → upgrade trap
"We're several versions behind" → stranded
"Developers have production access, it's more efficient" → control failure
"We don't really have a test environment" → chaos
"Data migration is planned for the last month" → will slip
"We don't have documentation, ask Karim, he knows everything" → bus factor 1
"Testing is done by the developers" → no UAT
None of these are automatically disqualifying — every real system has some technical debt, and a role fixing it can be a good one. But you should know what you’re walking into and negotiate accordingly.