What to expect
A customer changes subscription plans halfway through a billing period. Usage arrives late, the pricing table has changed, and a retry submits the same event twice. Can you explain the invoice without charging twice? That is a useful starting point for Acuiti Labs preparation because it connects programming decisions to a concrete business outcome.
Acuiti Labs describes its work in SAP revenue management and quote-to-cash consulting. SAP's partner directory identifies expertise in SAP BRIM, subscription monetisation, billing, and revenue management. These sources establish a business context, not a guarantee that every Software Engineer opening uses the same SAP module or interview format. Match your preparation to the exact team and posting.
The strongest practice material for this context concerns precision, traceability, and integration boundaries. A technically successful request can still create an incorrect bill. Prepare to explain how your code preserves business meaning when source systems disagree, contracts change, or data arrives after a reporting cutoff.
A billing-focused preparation strategy
Divide the problem into usage collection, rating, billing, and reconciliation. Collection records what happened; rating applies a rule; billing turns charges into a document; reconciliation checks agreement across records. Treating them as one opaque step makes failures difficult to diagnose. In an interview, define these boundaries before naming a queue or framework.
Ask whether the job involves application development, SAP configuration, integration, or production support. For a development role, practise data structures and service contracts. For an integration role, add payload mapping, effective dates, and restart behaviour. For a support-heavy role, prepare a discrepancy investigation that begins with an invoice identifier and ends with a proven cause. These are suggested directions, not a confirmed hiring scorecard.
Coding case: tiered usage charges
Original practice exercise: calculate a charge in integer cents for a non-negative integer number of units. The first 100 units cost 10 cents each, the next 100 cost 8 cents each, and all remaining units cost 5 cents each. Zero units costs zero. The pricing rules are invented for this exercise.
Start with examples rather than code: 100 units costs 1,000 cents; 101 costs 1,008; 200 costs 1,800; 250 costs 2,050. A frequent mistake is applying the final tier's rate to all units. State whether tiers are marginal or volume-based before implementing either interpretation.
One implementation consumes units tier by tier. Maintain remaining and total_cents; for each bounded tier, charge the smaller of its capacity and the remaining units, then subtract that quantity. Apply the final rate to the remainder. With a fixed number of tiers, the work is constant; for a configurable list of k tiers, it is O(k). Validate negative quantities, non-integer inputs, and malformed tier definitions at the boundary.
Next introduce a plan change. Do not silently rate an old usage event against today's price. Give the event an occurrence time and select the versioned pricing rule valid at that time. Explain what happens when there is no valid rule or two overlapping versions: flag the ambiguity for resolution instead of inventing a rate. If proration is required, obtain its units, rounding policy, and effective-time convention before calculating it.
The exercise should finish with a small test table covering zero, every tier boundary, one unit beyond a boundary, invalid input, and a changed price version. In a project discussion, show the exact arithmetic you can reproduce. Avoid claiming financial correctness merely because a floating-point calculation looks close enough on one example.
SQL case: find events that never became charges
Assume usage_events(id, account_id) and charges(id, event_id, amount_cents). Find events with no charge at all. An amount of zero is a valid charge, so it must not be interpreted as missing.
SELECT e.id, e.account_id
FROM usage_events AS e
WHERE NOT EXISTS (
SELECT 1
FROM charges AS c
WHERE c.event_id = e.id
)
ORDER BY e.id;
Use three fixtures: one event with a positive charge, one with a zero charge, and one with no charge. Only the last should appear. This is a missing-record check, not a complete reconciliation: two charges for one event are a separate problem. Add a uniqueness constraint only if the business contract permits exactly one charge per event; split allocations may require a richer key.
For an operational report, exclude events still within an agreed processing delay and show the oldest unprocessed event's age. Otherwise a normal short lag can be mistaken for a defect. Establish how late-arriving usage, rejected events, and intentionally non-billable events are represented before escalating discrepancies.
Design case: replayable usage-to-invoice processing
Begin with an immutable usage record containing its source identifier, account, occurrence time, unit, and quantity. Validate the unit and preserve the original payload or a controlled reference to it. Transformations should be traceable: if a source sends megabytes and the rating service expects gigabytes, the conversion is a business decision that deserves a test.
Separate the received event from the rated result. Store which pricing version produced the result, along with the amount and currency. A replay must either reproduce the original calculation under the same rule or explicitly create a corrected result under a new version. Overwriting history makes a later discrepancy much harder to explain.
Choose a durable deduplication key scoped to the source and account where appropriate. Checking for a duplicate and writing a result must be protected against concurrency. A process-local set will not prevent duplicates after restart or across two workers. Describe the storage guarantee you depend on instead of saying the system has exactly-once delivery.
Invoice assembly should consume an explicitly defined set of eligible charges. State the cutoff, how late events are handled, and whether a finalised invoice can change. For this exercise, freeze finalised invoices and model subsequent adjustments as separate records linked to the original. Confirm any actual commercial rules with the relevant business owner.
Use a reconciliation job to compare counts and totals by account, currency, and period. Counts alone can agree while values differ. Totals can agree while two offsetting errors hide inside them. Preserve a drill-down from the aggregate discrepancy to individual event identifiers, and report processing failures separately from genuine zero charges.
Debugging: a customer's invoice doubled overnight
Start by comparing invoice lines, not by restarting workers. Are the same usage identifiers present twice, or did the quantity double before rating? Did two rating versions produce records that invoice assembly treated as independent charges? Compare the raw event, deduplication decision, rated result, and assembly membership for one affected line.
Determine whether the problem followed a replay, a deployment, or a source-system resend. Preserve enough evidence to reconstruct the path. If a replay is necessary, demonstrate that the deduplication key and business state make it safe before running it. Replaying everything without a correction plan can multiply the problem.
Describe recovery as a controlled business operation: identify affected invoices, produce a candidate correction report, check it against known examples, and retain an audit trail. A good interview answer names both a short-term containment measure and the invariant that would prevent the same class of error.
Show that you can work across technical and billing teams
Prepare a story about resolving a disagreement over data meaning. Perhaps an API field called date meant processing date to one team and service date to another. Explain how you established the intended meaning, wrote a concrete example, and made the contract testable. The useful signal is your reasoning and communication, not whether your previous project involved SAP.
Ask the interviewer which part of quote-to-cash the role owns, how pricing changes are tested, who approves corrections, and how integration incidents are investigated. These questions are grounded in the company's published business context while leaving room for the actual team's responsibilities.
Your practice deliverables
Complete a boundary-tested tier calculator, the missing-charge query, a replay diagram, and a one-page invoice-discrepancy investigation. If you have extra time, introduce multiple currencies and explain why totals must be grouped rather than added blindly. Then introduce a retroactive contract correction and distinguish recalculation from historical explanation.
A two-week plan with concrete outputs
This is a suggested study schedule, not a description of Acuiti Labs's hiring timeline. Adjust it to the current job description and the time you actually have. If the recruiter confirms a different emphasis, move time toward that assessment instead of completing every exercise mechanically.
Days 1–3: turn the coding case into an executable contract
Implement the tiered pricing exercise in your strongest interview language. Before coding, write the input shape, invalid-input policy, tie-breaking rule, and expected output. Keep one deliberately small example that you can trace by hand. Add a test for each boundary described in the exercise rather than relying on a large random input to discover mistakes.
After the first working version, explain why your chosen data structure fits the operations you need. State both time and space costs, including retained retry history or copied state where relevant. Then change one requirement and identify which assumption breaks. Your goal is to demonstrate controlled reasoning when a problem changes, not to memorise one implementation.
Days 4–5: prove the SQL result on a tiny dataset
Create the tables used in the SQL case and insert a normal record, a missing-related-record case, and a duplicate or irrelevant record. Predict the output before executing the query. Check whether the result is one row per entity or one row per event, and whether null means missing data, unknown state, or a legitimate business value.
Explain how a join can multiply rows and why filtering a joined table in the wrong place can remove the very records you are looking for. For performance, begin with the lookup keys and expected access pattern; inspect an execution plan before promising that an index will solve the problem. Keep correctness and performance as separate review questions.
Days 6–9: draw the state boundary and break it
Use the architecture diagram as a starting point, then mark the operation that must be atomic. Write down what the caller is entitled to believe after a success response. For this case, make an immutable usage record and its pricing version visible in your explanation. Identify which later steps may still be pending even after the main operation succeeds.
Now simulate a price change arriving after the invoice cutoff. Record the state before the failure, the durable evidence after it, and the next action each component takes. A useful recovery story explains how the system distinguishes an incomplete operation from a completed operation whose response was lost. It also states what an operator can inspect without making the incident worse.
Days 10–12: practise diagnosis and communication
Rehearse the incident where replaying a batch doubles an invoice. Give yourself a short log extract or a handful of records rather than omniscient knowledge of the bug. Separate observations from hypotheses. Name the first query or trace you would inspect and explain which competing explanations its result would rule out.
Prepare one experience from your own work that demonstrates similar judgment. Describe the constraint, the decision you personally made, and the evidence that the change helped. If you do not have production experience, use a course or personal project honestly and explain the additional controls a production deployment would require.
Days 13–14: run a mock and repair the weakest answer
Spend one session on coding and another on design. Ask your mock interviewer to challenge a hidden assumption rather than only checking the final answer. Afterward, choose one specific weakness: unclear failure semantics, an untested boundary, an ambiguous schema, or an explanation that begins with tools before requirements. Revise that artifact and run the same scenario again.
Frequently asked questions
Are these verified Acuiti Labs interview questions?
No. The coding, SQL, and design cases are original preparation exercises informed by the company's public business context. The linked sources establish that context; they do not verify that these prompts appeared in an interview. Use any current recruiter instructions as the authority for your actual assessment format.
Which language should I use?
Use a language in which you can implement and test the exercise clearly, unless the current role or assessment specifies one. Practise explaining your standard library choices and failure handling. A company product page is not enough evidence to infer the language required in an interview.
What should I prioritise if I have only a weekend?
Complete one tested coding solution, run the SQL example against a tiny fixture, and walk through the failure scenario above. Then prepare two concise project stories and questions about the actual team. A small set of defensible answers is more useful than superficial familiarity with every possible technology.
For broader practice, use the PracHub Software Engineer question bank. Its questions are general role practice and should not be treated as verified questions from Acuiti Labs.