Comparing NetSuite Proposals with an Assumption Register

Compare NetSuite implementation proposals by converting their assumptions into explicit, testable conditions. Record which party owns each condition, what evidence supports it and how the scope changes if it is false. This makes differences between proposals visible before a headline fee or a delivery date drives the decision.

The register complements the commercial proposal and statement of work. It does not replace legal review or create commitments a supplier has not accepted. Its purpose is to expose the operational conditions behind a quoted approach so procurement, finance and delivery owners can compare like-for-like work.

Extract assumptions from the entire proposal

Look beyond a section labeled Assumptions. Conditions often appear in a timeline note, a scope description, an exclusion, a responsibility chart or a statement about standard functionality. Copy the relevant wording into the review record with its location and proposal version.

Watch for phrases such as customer-provided, standard integration, clean data, one legal entity, limited revisions and business-hours support. These phrases can be reasonable, but each needs a concrete interpretation for your project.

Ask what must already be true for the proposed effort to work. A data migration line may assume mappings have been approved, duplicate records resolved and source files delivered in a specified format. If those activities are absent from both parties' plans, the project contains an ownership gap.

Keep explicit exclusions separate from uncertain assumptions. A supplier that clearly excludes historical transactions has stated a scope boundary. A supplier that says data migration is included without describing history has left a question to resolve.

Give every assumption a consequence

A useful register contains the statement, affected deliverable, owner, evidence, confidence, decision deadline and consequence if false. Link it to the relevant requirement or scenario so reviewers can see why it matters.

Write the consequence as an operational change before assigning money. If the source lacks required identifiers, the team may need a mapping exercise and another rehearsal. That can consume internal capacity and move dependent tests even before a supplier prices additional services.

Do not assign arbitrary probability percentages merely to make a spreadsheet look quantitative. Use evidence-based states such as verified, awaiting sample, contradicted or accepted with conditions. A clearly stated unknown is more useful than unsupported mathematical precision.

Identify who can resolve the condition. An implementation consultant cannot verify a bank's file-approval timeline on the bank's behalf. The responsible finance or banking contact must obtain the relevant confirmation.

Normalize the scope before comparing price

Create a common comparison baseline using the actual business requirements. Include subsidiaries, users, locations, key processes, migration objects, integrations, reports, testing cycles, training and launch support where relevant. Ask each provider to mark included, excluded or awaiting clarification.

Keep units consistent. One proposal may include ten reports while another includes ten report-building days. One may include integration discovery while another includes a working interface with recovery and reconciliation. These are not equivalent quantities.

Compare acceptance and operating responsibility as well as build activity. A connector installed successfully may still require mapping, role testing, error handling and business reconciliation. Identify which party supplies each result and who approves it.

Separate recurring third-party subscriptions from implementation services and internal effort. Do not assume a demonstrated application is covered by the NetSuite subscription or the partner fee. Request the actual entitlement and commercial confirmation for the proposed arrangement.

Examine data and integration assumptions closely

For each migration object, specify whether the proposal covers extraction, cleansing, mapping, loading, reconciliation and correction. Identify the number and purpose of rehearsals. A load-only scope can be acceptable when the customer genuinely owns the preceding work and has capacity to do it.

Ask for a representative data sample review before accepting a clean-data assumption. Include blanks, duplicates, obsolete references and a complex transaction. Do not send confidential production material more widely than the evaluation requires.

For integrations, define source and target systems, record operations, direction, event timing, volumes and failure ownership. “Standard connector” does not establish that every custom field, return or amendment is supported.

Record dependence on other suppliers. Credentials, test environments, interface specifications and provider review queues can affect the schedule. A date that assumes immediate third-party availability needs confirmation from that third party.

Compare the client's workload explicitly

List decisions, data preparation, workshops, testing and training that require internal staff. Estimate capacity using named roles and known calendars. Avoid treating every task assigned to the customer as free or instantly available.

Inspect sequencing. The controller may be responsible for both opening-balance reconciliation and UAT during close. A proposal can be internally consistent on consultant hours while impossible for the client's actual team to support.

Ask how delayed decisions affect the plan. The answer should distinguish a short pause, resequencing, resource availability and a potential change request. Confirm the applicable commercial terms through the authorized review process rather than inferring them from workshop conversation.

Include post-launch responsibilities. Clarify who handles incidents, what qualifies as a defect, how requests are prioritized and what evidence closes an issue. A named hypercare period is insufficient if nobody knows which work it includes.

Hypothetical example of two migration proposals

A fictional company compares two proposals for the same eight migration objects. Proposal A includes extraction and loading for all eight, but assumes the customer cleanses and reconciles the data. Proposal B includes loading for all eight and supplier-led reconciliation for six; two specialist objects remain customer-owned.

The buyer initially marks both proposals as eight objects included. The assumption register reveals that this count describes object coverage, not identical responsibility. It records 16 object-stage combinations for cleansing and reconciliation: eight objects multiplied by two preparation or verification stages.

Review shows the internal team can own ten of those combinations with its available skills, while six need an agreed external owner or additional preparation. This is a planning model, not a claim that every object requires equal effort.

The providers are asked to revise their responsibility descriptions and clarify the six uncovered combinations. The comparison then considers the agreed work, capacity and evidence. The buyer does not invent a surcharge or declare one quote cheaper before that clarification arrives.

Turn clarification into a controlled decision

Send grouped, specific questions to each provider. Quote the relevant assumption, state the business fact and ask how it affects scope, timing, ownership and acceptance. Keep the answer tied to the proposal version.

Distinguish an explanation from a binding amendment. If the answer materially changes delivery or fees, route it through the organization's commercial approval process and obtain the appropriate revised documents. A helpful email may not update every conflicting clause.

Retain unresolved conditions in the recommendation. Explain which are acceptable with an owner and which prevent a reliable commitment. A proposal can remain viable while one essential dependency needs proof.

Avoid penalizing a provider simply for documenting more assumptions. Explicit conditions can be a sign of careful scoping. The comparison should reward realistic ownership and verified fit rather than the shortest list of caveats.

Carry the register into delivery

Once a provider is selected, transfer the approved assumptions into kickoff and planning. Assign review dates to conditions that remain open. When an assumption changes, assess the linked requirements and milestones instead of discovering the consequence at invoicing.

Close verified assumptions with their evidence. Preserve rejected or superseded entries so the team can explain why the baseline changed. The register should become smaller and more certain as discovery progresses.

An independent scope review with CuriousRubik's NetSuite support services can help make technical and operational assumptions comparable. Procurement and authorized legal reviewers still decide the final commercial commitments. The immediate outcome is a decision based on understood work rather than a misleadingly similar proposal heading.

Frequently asked questions

Is an assumption the same as an exclusion?

No. An exclusion states that work is outside scope. An assumption describes a condition underlying the proposed approach. If that condition fails, additional work or a changed design may be needed.

Should the proposal with fewer assumptions win?

Not automatically. Fewer written assumptions can mean simpler scope or less explicit scoping. Compare whether important conditions are verified and responsibilities are complete.

Can internal effort be ignored because it is not a supplier fee?

No. Decisions, cleansing, testing and training consume real capacity and can constrain the schedule. Record the accountable roles and availability even when no additional invoice is expected.

Should uncertain costs be filled with market averages?

Avoid presenting unsupported figures as a project estimate. Obtain scoped supplier clarification and identify remaining uncertainty. Clearly labeled planning scenarios should retain their assumptions and limitations.

When does the assumption register stop being useful?

It remains useful until material conditions are verified, superseded or explicitly accepted. Carry unresolved items into delivery and link changes to the approved scope and decision process.