Case Study

Our customer needed a more efficient way to pre-authorize credit cards before sending sales orders to the warehouse. Previously, their process involved taking the order, fulfilling it, updating the sales order with the shipping cost, and then creating the invoice to apply a customer payment.

To improve efficiency and reduce errors, we implemented a workflow that allows the credit card to be pre-authorized as soon as the sales order is created—before it reaches the fulfillment stage and then change the amount of payment once the shipping cost was calculated . This proactive approach helps prevent cancellations of billed sales orders, minimizes unnecessary work, and eliminates potential mistakes during fulfillment.

This post highlights how automating the pre-authorization process not only streamlines operations but also strengthens cash flow control and improves customer experience. By securing payment before fulfillment, your team can confidently release orders to the warehouse, knowing that the funds are verified and ready to capture once the order is completed.

Another requested feature—applying open credits and payments at the sales order level—further enhances the process by ensuring that any customer balances or prepayments are automatically linked to the correct orders, reducing manual reconciliation work. We will visit this in our next post.

In this sales process, the cycle begins with a Quote, where the sales representative specifies the customer, items, and any relevant instructions such as “Free Shipping” or “Money on Account”.
Once the quote is converted to a Sales Order, which proceeds through Item Fulfillment, and eventually generates an Invoice.

This new requirement introduced technical and accounting challenges:

NetSuite Behavior After Authorization

When a credit card is authorized on a Sales Order in NetSuite, subsequent fulfillment automatically generates a Cash Sale instead of an Invoice.

This default behavior aligns with NetSuite’s logic that “authorized + fulfilled” transactions are immediately payable.

However, this became problematic because Cash Sales cannot have Credit Memos or Customer Payments applied to them, even though official NetSuite documentation suggests otherwise.
After extensive testing, we confirmed that Credit Memos can only be applied to open Invoices, not Cash Sales.

This meant that once the card was authorized, no credits can be applied, breaking the client’s accounting rules and customer expectations.

Shipping Cost Uncertainty

For customers with “Prepaid and Charge” terms, shipping costs are not known until the Item Fulfillmentrecord is created.
However, the business requirement was to authorize the full amount before fulfillment.

To solve this, we designed an approach to estimate shipping at 10% of the total item cost during the Quote stage.

This allows the system to authorize an amount close to the final total without waiting for the actual shipping rate.

Applying Customer Credits and Customer Payments

This to be discussed in our next post

The Solution Design

Shipping Estimation Logic

When a Quote is created and the customer’s terms are “Prepaid and Charge,” the system automatically:

• Calculates 10% of the total item value.
• Adds it as a temporary Shipping Cost.
   Example:
   If items total $100, estimated shipping = $10 → total to authorize = $110.

When the actual fulfillment happens, the real shipping cost replaces the estimate, and the captured amount reflects the true total.

Custom “Credits to Apply” Subtab

We developed a custom tab available on both Quote and Sales Order records, labeled:
 “Credit Memos / Customer Payments to Apply.”

This subtab contains a dynamic sub-list that:

• Lists all open-period Credit Memos and Customer Payments for the same customer.
• Uses a Saved Search filtered by:
  • Transaction type (Credit Memo or Customer Payment)
  • Remaining amount > 0
  • Accounting period = Open
• Provides user interaction fields:
  • Checkbox to select which credits to use
  • Display-only fields for document number, type, original amount, and remaining balance
  • Editable Amount to Apply field (with validation)

Validations enforced:

• The entered “Amount to Apply” cannot exceed the record’s available balance.
• The sum of all applied credits cannot exceed the Sales Order total.

Adjusting the Authorized Amount

When the user selects available credits:

• The total credit amount is summed up.
• The system adds a Discount Item line in the transaction body, representing that total as a negative value.
• The final authorization amount = total order – total credits.

Example:
If the order total is $110 and the customer applies $50 in credits, the authorized amount will be $60.

Dummy Invoice Creation

Because Credit Memos and Customer Payments cannot be applied to Cash Sales, we introduced an intermediate record — the “Dummy Invoice.”

When the Sales Order is saved:

• A User Event script checks if credits are selected.
• If so, it creates an Invoice with:
  • Same customer, location, department, and currency as the Sales Order.
  • No item lines, except for one Service Item line per selected credit record.

Giving as result; Invoice total amount = credit amount to apply.

• Immediately after creation, the script applies the corresponding Credit Memos and Customer Payments to this dummy Invoice via the apply sub-list in SuiteScript.

This ensures that the credits are marked as used in NetSuite, preventing reapplication, while keeping the main Sales Order available for CyberSource authorization and later Cash Sale creation.

Scenario-Based Behavior

During implementation, several possible payment scenarios were identified, each requiring a distinct workflow.
The following section describes the behavior of the system for each case, the validations applied, and how CyberSource and NetSuite respond under those conditions.

Scenario 1 — No Customer Credits Available

Condition:
 The customer has no available Credit Memos or Customer Payments.
 The entire order amount must be paid via credit card.

Flow:

1. When the Sales Order is created, the customer’s credit card information is entered and sent to CyberSource for authorization.
2. The authorization request is approved, meaning the customer’s card has sufficient funds.
3. Once the Item Fulfillment record is set to Shipped, the Cash Sale is created by the user.
4. The Cash Sale captures previously authorized funds through CyberSource.
5. The Payment Events tab confirms the successful capture, completing the sales cycle.

Outcome:
 A standard “authorized capture” flow with no credit application. The Sales Order transitions smoothly from authorization to fulfillment to Cash Sale.

Scenario 2 — Partial Payment Using Credits and Credit Card

Condition:
 The customer will partially pay the order using credits on account and cover the remaining balance with a credit card.

Flow:

1. On the Sales Order, the Credits to Apply subtab lists available Credit Memos and Customer Payments.
   1. The user selects which credits to apply.
   1. A Discount Item line is added to the Sales Order representing the total of selected credits.
2. The authorization request to CyberSource is sent for the remaining amount only (total – credits).
3. When the authorization is successful:
   1. A User Event Script creates a Dummy Invoice that mirrors the Sales Order (same customer, location, department, and currency),
       but without copying any item lines.
   1. Instead, one Service Item line is added per credit record selected; each line representing the corresponding applied amount.
   1. The total amount of this Dummy Invoice equals the total discount from the Sales Order.
4. Immediately after creation, the script opens the Dummy Invoice and applies the selected Credit Memos and Customer Payments using the apply sublist.
    This marks those records as used and prevents reapplication.
5. The main Sales Order remains active for the authorized portion, which will convert into a Cash Sale upon fulfillment.

Example:
If the Sales Order total is $100, and the customer applies $50 in credits, only $50 is authorized through CyberSource.
The Dummy Invoice is created for $50 and used to consume the credits.

Outcome:
Credits are properly consumed through a separate Invoice record, while the remaining balance is processed via credit card authorization and later captured.

Scenario 3 — Fully Paid with Customer Credits

Condition:
The customer has enough Credit Memos or Customer Payments to cover the full Sales Order amount.
No card authorization is needed.

Flow:

1. The Sales Order displays:
   1. Item subtotal and (optional) shipping cost.
   1. A Discount Item equal to the total of applied credits.
   1. A final transaction total of $0.
2. This is the only scenario where the Sales Order can be edited after creation, because the final shipping cost might be unknown until fulfillment.
   1. Once the Item Fulfillment record is available, the true shipping amount is updated.
   1. The Sales Order is then adjusted so that total credits = final total amount.
3. When the order total reaches $0, a User Event transforms the Sales Order into an Invoice.
   1. Since no credit card is involved, the transform is allowed.
   1. The script removes the Discount Item and its rate from the new Invoice, as it only serves as a visual representation of credits at the Sales Order level.
4. This Invoice becomes the final payment record, equivalent to the Cash Sale in a credit card flow.
5. The script automatically applies the corresponding Credit Memos and Customer Payments to the Invoice.
   The Invoice is saved in status “Paid in Full.”

Outcome:
The entire order is paid with existing credits.
The resulting Invoice reflects all applied records under Related Records → Payments, confirming that no authorization was required.

Scenario 4 — Authorization Failure (No Credits)

Condition:
 The Sales Order has no credits applied, but the CyberSource authorization fails.

Flow:

1. Upon saving, the system attempts authorization with CyberSource.
2. If the authorization fails:
   1. The Sales Order is automatically closed.
   1. A notification is displayed to the user showing CyberSource’s error message (e.g., Insufficient Funds, Invalid Card Number, Expired Card).
   1. The user must create a new Sales Order once the issue is resolved.

Outcome:
The failed Sales Order is closed.
This prevents accidental reuse or double processing of payment data.

Scenario 5 — Partial Credits + Authorization Failure

Condition:
The Sales Order includes credits to apply and still requires partial authorization through CyberSource, but the authorization fails.

Flow:

1. The Sales Order is saved and triggers an authorization attempt.
2. The authorization fails.
3. The system closes the Sales Order and does not create the Dummy Invoice.
   1. Since the authorization failed, no credits are applied.
   1. The customer’s credits remain available for future use.

Outcome:
No financial impact occurs.
Credits are not consumed, and the user can safely create a new Sales Order to retry authorization.

Validation Logic

To maintain data integrity, the following checks are enforced before saving the Sales Order record:

• When credits are selected:
  • Each Credit Memo or Customer Payment must have status = Open.
  • The amount to apply cannot exceed the available balance (remaining).
  • The sum of applied credits cannot exceed the order total.
• Before creating the Dummy Invoice:
  • The script verifies that CyberSource authorization was successful.
  • Only in that case are credits applied.
  • Otherwise, the order is closed, and no Invoice is generated.
• Any validation failure returns an error to the user, clearly stating whether:
  • The selected credit record was already applied, or
  • The amount entered exceeds the available balance.

This implementation successfully bridged the gap between NetSuite’s native payment flow and the business requirement to authorize funds early while still honoring existing customer credits.
By combining the CyberSource Payment Bundle, a custom “Credits to Apply” feature, and a controlled “Dummy Invoice” process, the requirements achieved an automated payment workflow that remains compliant with both accounting rules and CyberSource’s transaction model.

The resulting solution minimizes human intervention, prevents double application of credits, and provides clear visibility into every financial event — from authorization to final payment.
It also ensures that customers with funds on account are accurately credited before any charge is made to their card, improving both user experience and reconciliation accuracy.

Skype Chat

Skype Call