DEV Community: Himanshu

Managing Custom Invoice Hold for Under Paypables Invoicing in Oracle Fusion Payables Using REST APIs

Himanshu — Mon, 19 Oct 2026 04:02:49 +0000

Introduction

Purchase order matching is an important part of invoice processing in Oracle Fusion Cloud Payables. It helps organizations validate supplier invoices against purchase orders and receiving transactions before payment.

However, not every business requirement can be addressed through standard matching rules.

Consider a scenario where a purchase order has been created for 10 units and the complete quantity has already been received. During invoice creation, the user matches only 4 units against the purchase order.

From a standard matching perspective, this is generally an acceptable transaction. The invoiced quantity does not exceed the received quantity.

But suppose the business requires an additional control: once the full purchase order quantity has been received, an invoice matched for a lower quantity should be placed on hold for review.

In this article, I will walk through how this requirement can be addressed using Oracle Fusion Payables, a custom invoice hold, and REST API-based validation.

The focus is on extending standard invoice controls without changing the underlying purchase order matching process.

1. Understanding the Business Requirement

Let's consider the following transaction.

Transaction	Quantity
Purchase Order Quantity	10
Received Quantity	10
Invoice Matched Quantity	4
Quantity Difference	6

The purchase order has been fully received, but the invoice has been matched for only part of the received quantity.

The business expects the system to identify this difference and apply a custom hold to the invoice.

The invoice should remain unavailable for payment until the discrepancy has been reviewed and the hold is released.

Why is an additional control required?

Oracle Payables supports partial invoicing. A supplier may legitimately invoice fewer units than those received.

For example, if 10 units have been received but the supplier invoices only 4 units, standard matching does not necessarily consider this an exception.

In this particular scenario, however, the business wants to review such transactions before payment.

The requirement is therefore not to replace standard invoice matching, but to introduce an additional validation based on the organization's invoicing policy.

2. Standard Oracle Payables Matching vs. Custom Validation

Before configuring the solution, it is important to distinguish between standard matching and the proposed custom control.

Oracle Fusion Payables supports different matching options, including two-way, three-way, and four-way matching.

Under three-way matching, the invoice is validated against purchase order and receipt information, subject to the configured matching rules and tolerances.

Standard quantity matching is primarily concerned with situations where invoiced quantities exceed the permitted ordered or received quantities.

In our example:

Received Quantity = 10

Invoiced Quantity = 4

The invoiced quantity is lower than the received quantity.

Therefore, a standard quantity matching hold would not normally be applied solely because of this difference.

The custom requirement is different:

If the invoiced quantity is less than the applicable received quantity, identify the transaction and place the invoice on hold for review.

This condition will be evaluated through a custom integration.

3. Solution Design

The proposed solution involves Oracle Fusion Procurement, Receiving, Payables, and REST APIs.

The overall process is:

The REST API integration will be responsible for retrieving the required information, performing the comparison, and applying the configured invoice hold.

4. Create the Purchase Order

The first step is to create a purchase order in Oracle Fusion Procurement.

For this demonstration, I will use a single purchase order line with a quantity of 10 units.

Attribute	Value
Purchase Order	US165400
Item	Item001
Quantity	10 Units
Unit Price	$40
Total Amount	$400

After entering the required details, submit the purchase order for approval.

Once approved, the purchase order will be available for receiving.

Screenshot 1: Approved Purchase Order with Quantity of 10 Units

5. Complete the Receiving Transaction

The next step is to perform the receiving transaction against the purchase order.

For this scenario, the complete quantity of 10 units will be received.

The transaction will have the following details:

Description	Quantity
Ordered Quantity	10
Received Quantity	10
Remaining Quantity to Receive	0

The receipt must be successfully processed before proceeding with invoice matching.

This is important because the custom validation will compare the invoiced quantity with the applicable received quantity.

Screenshot 2: Receipt Completed for 10 Units

6. Create the PO-Matched Payables Invoice

Once the receiving transaction is completed, navigate to Oracle Fusion Payables.

Navigation:

Payables → Invoices → Create Invoice

Create an invoice for the supplier and select the purchase order for matching.

Although the purchase order has been received for 10 units, enter an invoice quantity of 4 units.

Assuming a unit price of $100, the invoice amount will be $400.

Attribute	Value
Invoice Number	INVOICE_101
Purchase Order	US165400
Received Quantity	10
Invoice Quantity	4
Invoice Amount	$400

Save the invoice and complete the applicable matching steps.

At this point, the invoice is matched for a quantity lower than the received quantity.

Under standard matching rules, this difference alone would not normally result in a quantity matching hold.

Our custom validation will now evaluate the transaction.

Screenshot 3: Payables Invoice Matched for 4 Units

7. Configure the Custom Invoice Hold

The next step is to define a custom invoice hold in Oracle Fusion Payables.

Navigation:

Setup and Maintenance → Manage Invoice Holds and Releases

For this scenario, the proposed hold name is:HB_Invoice_Hold

Partial PO Invoice Quantity Hold

The hold will be used to identify invoices that require additional review because the matched invoice quantity is lower than the received quantity.

A user-defined hold name can be associated with a supported hold type, such as Invoice Hold Reason.

The hold configuration should be reviewed to determine whether accounting is permitted while the invoice is on hold.

For this example, the primary requirement is to restrict payment processing.

One important distinction is that defining a hold name does not automatically evaluate the difference between invoiced and received quantities.

The custom integration will perform that validation and explicitly apply the configured hold.

Screenshot 4: Custom Invoice Hold Configuration

8. Retrieve Invoice Details Using REST API

Once the invoice is created, the integration needs to retrieve the relevant invoice information.

Oracle Fusion Cloud Financials provides REST APIs for accessing Payables invoice data.

The Payables Invoices REST resource can be accessed using the following endpoint:

GET /fscmRestApi/resources/11.13.18.05/invoices

The integration should identify the invoice using the appropriate invoice reference and retrieve its matched line information.

The required business data includes:

Invoice identifier
Invoice number
Purchase order reference
Purchase order line or schedule reference
Matched invoice quantity

The quantity should be retrieved from the relevant invoice line or matching information, rather than assuming it is an invoice header attribute.

For this scenario, the matched invoice quantity is 4 units.

Screenshot 5: REST API Response Showing Invoice Details

9. Retrieve the Receiving Quantity

The integration also needs to retrieve the receiving information associated with the purchase order.

The required information includes the purchase order reference, receiving transaction details, and applicable received quantity.

For our example:

Purchase Order: PO-1001

Received Quantity: 10 Units

The integration must ensure that the invoice quantity and received quantity belong to the same purchase order matching reference.

This becomes particularly important when a purchase order contains multiple lines, schedules, or receipts.

For the current demonstration, we are considering a single purchase order line with one completed receipt.

Screenshot 6: Receiving Information Retrieved Through REST API

10. Perform the Custom Quantity Validation

Once the invoice and receiving quantities have been retrieved, the integration will compare them.

The validation condition is:

IF Invoiced Quantity < Received Quantity

THEN
    Identify Invoice for Custom Hold

ELSE
    No Custom Hold Required

For our example:

Received Quantity = 10

Invoiced Quantity = 4

Quantity Difference = 6

Since 4 is less than 10, the condition is satisfied.

The invoice will therefore be identified for custom hold processing.

This validation represents the business requirement rather than standard Oracle Payables matching behavior.

For a production implementation, the rule should also define whether the comparison is based on the current invoice or cumulative quantities across all relevant invoices.

11. Apply the Invoice Hold Using REST API

Oracle Fusion Cloud Financials provides an Invoice Holds REST resource that supports creating and managing invoice holds.

The create operation uses:

POST /fscmRestApi/resources/11.13.18.05/invoiceHolds

The integration will use the appropriate invoice identifier and configured hold name to apply the hold.

For this scenario:

Attribute	Value
Invoice	INVOICE_101
Hold Name	Partial PO Invoice Quantity Hold
Received Quantity	10
Invoiced Quantity	4
Quantity Difference	6
Expected Action	Apply Invoice Hold

The actual request payload must follow the Oracle REST API schema supported by the environment.

Before creating a hold, the integration should check whether the same active hold already exists against the invoice.

This avoids creating duplicate holds if the integration is executed more than once.

Once the request is processed successfully, the integration should capture the response and verify that the hold was created.

Screenshot 7: REST API Request and Successful Response

12. Verify the Invoice Hold in Payables

After applying the hold through REST API, navigate back to Oracle Fusion Payables.

Navigation:

Payables → Invoices → Manage Invoices

Search for the invoice and open the Holds section.

The expected result is:

Description	Expected Result
Invoice Number	INVOICE_101
Invoice Quantity	4 Units
Received Quantity	10 Units
Custom Hold	Applied
Payment Processing	Restricted

The custom hold should be visible against the invoice.

The invoice will remain restricted from payment while the hold is active.

It is important to distinguish this from preventing further invoice entry. A manual invoice hold does not, by itself, prevent users from editing invoices or creating additional invoices against the purchase order.

If the business requires those restrictions, they must be addressed separately.

Screenshot 8: Custom Hold Visible Against the Invoice

13. Release the Invoice Hold

The final step is to define how the invoice hold will be released.

The hold should remain active until the quantity difference has been reviewed and the required business action has been completed.

For example, the supplier may submit another invoice for the remaining quantity, or the existing invoice may require correction.

The integration should not assume that receiving or invoicing additional quantities automatically releases a manually applied hold.

The release process must be explicitly designed and tested.

Depending on the business requirement, the hold may be released manually by an authorized user or through the supported REST API functionality.

Screenshot 9: Invoice Hold Released After Review

14. Additional Considerations for Production Implementation

The example above uses a single purchase order line to explain the process.

In actual implementations, there are several additional conditions to consider.

Multiple Purchase Order Lines

The integration should compare quantities at the appropriate purchase order line or schedule level.

Comparing only purchase order header totals may lead to incorrect results.

Multiple Receiving Transactions

A purchase order line may be received through several transactions.

The calculation should consider the applicable net received quantity, including corrections and returns where required.

Multiple Payables Invoices

A supplier may submit multiple invoices against the same purchase order.

The business must decide whether the hold should be based on the current invoice quantity or cumulative invoiced quantity.

Duplicate Hold Prevention

The integration should check for an existing active hold before applying another hold to the same invoice.

Integration Timing

The timing of the REST API validation is important.

If the integration runs after invoice creation, the business must ensure that the invoice cannot be paid before the validation and hold application have completed.

Hold Release Controls

The release process should be documented and restricted to the appropriate users or integration process.

These considerations become important when moving the solution from a demonstration scenario to a production environment.

Key Takeaways

The main points from this scenario are:

Oracle Fusion Payables generally supports partial invoicing against purchase orders.
Standard matching does not normally place an invoice on hold simply because the invoiced quantity is lower than the received quantity.
A custom invoice hold can be configured to support an additional business review requirement.
REST APIs can be used to retrieve invoice information, compare quantities, and apply the configured hold.
The custom validation should use the appropriate purchase order matching references.
Hold creation, duplicate prevention, and release should be considered as part of the overall integration design.
A manual invoice hold restricts payment but does not automatically prevent additional invoice entry or editing.

Final Thoughts

In this article, I have covered a business scenario where a purchase order is created for 10 units, the complete quantity is received, but the Payables invoice is matched for only 4 units.

While Oracle Fusion Payables generally allows this type of partial invoicing, some organizations may require an additional review before allowing the invoice to proceed to payment.

The proposed solution uses REST APIs to retrieve the invoice and receiving information, compare the quantities, and apply a configured invoice hold when the business condition is satisfied.

The important part of this approach is understanding where standard Oracle matching ends and where a business-specific validation needs to be introduced.

This is particularly relevant when implementing additional financial controls without changing the standard purchase order and invoice matching process.

Have you worked on similar invoice validation requirements in Oracle Fusion Payables? Feel free to share your experience or connect with me to discuss other approaches.

Controlling Project Costs in Oracle Fusion PPM: Project and Task Transaction Controls

Himanshu — Mon, 05 Oct 2026 02:31:22 +0000

Controlling what can and cannot be charged to a project is an important part of project cost governance.

Oracle Fusion PPM provides Transaction Controls that allow organizations to define which transactions are chargeable or nonchargeable for specific projects and tasks.

Instead of relying on users to remember where certain costs should be charged, Transaction Controls allow these business rules to be enforced directly within Oracle Fusion.

In this post, we'll explore how Transaction Controls work and walk through a simple example where a specific Task + Expenditure Type combination is configured as nonchargeable.

What Are Transaction Controls?

Transaction Controls allow you to specify the types of transactions that can or cannot be charged to projects and tasks.

They can be used to configure projects and tasks so that only the charges expected or planned by the business are allowed.

Transaction Controls can also be used for additional purposes:

For billing-enabled projects, transactions can be defined as billable or nonbillable.
For capital projects, transactions can be defined as capitalizable or noncapitalizable.

This makes Transaction Controls useful not only for restricting project costs, but also for supporting billing and capitalization requirements.

What Can Be Controlled?

Oracle Fusion provides several attributes that can be used when defining Transaction Controls.

Transaction Control Component	Purpose
Expenditure Category	Control transactions for an expenditure category
Expenditure Type	Control a specific expenditure type
Nonlabor Resource	Restrict transactions for a nonlabor resource
Person	Control transactions for a specific person
Job and Organization	Apply controls based on a person's job and organization
Person Type	Control transactions based on person type
Chargeable Status	Define whether the transaction is chargeable
Billable / Capitalizable Status	Control billing or capitalization treatment
From and To Dates	Define when the transaction control is effective

These attributes can be used individually or in combination.

For example, a Transaction Control could be created for:

Person + Expenditure Type

or a more specific combination such as:

Person + Expenditure Type + Nonlabor Resource

This gives organizations flexibility to create controls based on their project governance requirements.

The Business Scenario

Let's use a simple example.

Assume we have the following project:

Project: Test_Transaction_Control

Below mentioned tasks will be considered:

Task Pre-Implementation

Task Change Management

We also have:

Expenditure Type: Expenditure Type Airfare

The business requirement is:

Expenditure Type Airfare should not be charged to Task Pre-Implementation

However, the same expenditure type can still be charged to other Task like Change Management.

The expected result is:

Task Pre-Implementation + Expenditure Type Airfare → Not Chargeable

Task Change Management + Expenditure Type Airfare → Chargeable

This is where a Task-level Transaction Control can be used.

Step 1 — Identify the Transaction to Restrict

The first step is to identify exactly what the business wants to prevent.

In our example:

Project: Test_Transaction_Control

Task: Pre-Implementation

Expenditure Type: Airfare

The requirement isn't to prevent Airfare from being used throughout the entire project.

We only want to prevent it from being charged to Task Pre-Implementation.

This is an important distinction because Transaction Controls can provide granular control at the task level.

Step 2 — Create the Task Transaction Control

Navigate to the appropriate Transaction Controls area for the project/task and create the required control.

For our example, the control would conceptually look like this:

Attribute	Value
Task	Pre-Implementation
Expenditure Type	Airfare
Type	Exclusive
From Date	As applicable
To Date	As applicable

The business rule is now represented within Oracle as:

Task Pre-Implementation

Expenditure Type Airfare

↓

Transaction Control

↓

Nonchargeable

This means Oracle can evaluate transactions against the control instead of relying solely on users to remember the restriction.

Step 3 — Attempt the Restricted Transaction

Now let's test the control.

A user attempts to create a project transaction using:

Project: Test_Transaction_Control

Task: Task Pre-Implementation

Expenditure Type: Expenditure Type Airfare

Oracle evaluates the transaction against the applicable Transaction Controls.

Because this specific combination has been configured as Exclusive Transaction Control, the transaction isn't permitted.

Upon validating the POET payables invoice, the invoice gets on system hold

Result: Transaction Not Allowed

Conceptually:

Step 4 — Test an Allowed Transaction

Now let's change the task while keeping the same expenditure type.

Project: Test_Transaction_Control

Task: Task Change Management

Expenditure Type: Expenditure Type Airfare

No applicable Transaction Control prevents this combination, the expenditure can be charged to Task Change Management.

Result: Transaction Allowed

Successfully Validated and invoice ready for accounting

This demonstrates an important point:

The Expenditure Type itself isn't necessarily restricted from the entire project. The control can determine where within the project that expenditure is chargeable.

How Oracle Evaluates the Business Rule

The functional logic can be visualized as:

This allows the business rule to be enforced before an unwanted cost is charged to the project/task.

Using Multiple Transaction Control Attributes

The Task + Expenditure Type example is intentionally simple.

In practice, Transaction Controls can be much more specific.

For example, an organization could define a rule using:

Task + Expenditure Type + Person

or:

Expenditure Type + Person + Nonlabor Resource

The applicable From and To Dates can further determine when the control is effective.

This makes Transaction Controls useful when project charging rules vary by resource, expenditure classification, organization, or period.

Chargeable vs Billable vs Capitalizable

These concepts serve different purposes and shouldn't be confused.

Control	What It Determines
Chargeable	Whether the transaction can be charged to the project/task
Billable	Whether the transaction can be considered for billing on billing-enabled projects
Capitalizable	Whether the transaction can be considered for capitalization on capital projects

For our example, we're primarily concerned with Chargeable Status.

The question Oracle needs to answer is:

Can Expenditure Type Airfare be charged to Task Pre-Implementation?

Our Transaction Control says:

No.

What Happens If No Transaction Controls Are Defined?

This is an important behavior to understand.

If Transaction Controls aren't defined, expenditure items from applicable persons, expenditure categories, expenditure types, and nonlabor resources can be charged to the lowest-level tasks on the project.

Transaction Controls therefore provide an additional governance layer when the business needs to restrict what can be charged.

Without our Task Pre-Implementation restriction, there would be no Transaction Control specifically preventing Expenditure Type Airfare from being charged to that task.

Why Use Transaction Controls?

Transaction Controls help move project charging rules from user knowledge into system-enforced controls.

Without a Transaction Control, the business might tell users:

"Don't charge Expenditure Type Airfare to Task Pre-Implementation."

With a Transaction Control, Oracle can enforce:

Task Pre-Implementation + Expenditure Type Airfare = Nonchargeable

This can help:

Prevent incorrect project charges
Enforce project-specific business rules
Improve project cost accuracy
Reduce downstream corrections
Strengthen project cost governance
Control billing and capitalization treatment where applicable

Common Transaction Control Scenarios

Transaction Controls can support many practical business requirements.

Restrict an Expenditure Type

Prevent a particular expenditure type from being charged to a specific task.

Restrict a Person

Prevent or allow transactions for a particular person.

Restrict by Person and Expenditure Type

Allow or prevent a specific person from charging a particular type of expenditure.

Apply a Date-Based Restriction

Use From and To Dates so that the Transaction Control applies only during a defined period.

Control Billing

For billing-enabled projects, determine whether applicable transactions are billable or nonbillable.

Control Capitalization

For capital projects, determine whether applicable transactions are capitalizable or noncapitalizable.

Key Takeaways

Transaction Controls determine which transactions are chargeable or nonchargeable for projects and tasks.
Controls can use attributes such as Expenditure Category, Expenditure Type, Nonlabor Resource, Person, Job, Organization, Person Type, and effective dates.
Multiple attributes can be combined to create granular project charging rules.
For billing-enabled projects, controls can also determine billable or nonbillable treatment.
For capital projects, controls can determine capitalizable or noncapitalizable treatment.
Task-level controls can restrict an expenditure from one task without necessarily preventing it from being used elsewhere on the project.
In our example, Task Pre-Implementation + Expenditure Type Airfare is nonchargeable, while Task Change Management + Expenditure Type Airfare remains chargeable, assuming no other applicable control prevents it.
Transaction Controls allow business rules to be enforced within Oracle rather than relying only on user training.

Final Thoughts

Project and Task Transaction Controls provide a flexible way to strengthen project cost governance in Oracle Fusion PPM. By combining attributes such as Task, Expenditure Type, Person, Organization, and effective dates, organizations can control which transactions are permitted before incorrect costs reach the project.

Once you understand the relationship between the transaction attributes and the Chargeable, Billable, and Capitalizable statuses, Transaction Controls become a powerful tool for enforcing project-specific business rules.

Have you used Project or Task Transaction Controls in Oracle Fusion PPM? Drop a comment below or connect with me. I would love to hear how you're using Transaction Controls in your implementations.

Oracle Fusion Projects Cost Capitalization: End-to-End Flow from Project Costing to Fixed Assets

Himanshu — Sat, 03 Oct 2026 19:14:57 +0000

Project Cost Capitalization in Oracle Fusion: From Project Costing to Fixed Assets

Project capitalization sounds simple on paper: collect project costs, identify what should become an asset, and transfer those costs to Fixed Assets.

In practice, there are several important stages between an expenditure hitting a project and a depreciable asset appearing in Oracle Fixed Assets.

Oracle Fusion provides an integrated capitalization flow between Project Costing and Fixed Assets, allowing organizations to collect costs against capital projects, accumulate qualifying costs as Construction in Progress (CIP), generate project asset lines, and ultimately transfer those costs to Fixed Assets.

In this post, I'll walk through the end-to-end capitalization process using a simple $2,000 example and explain what happens at each major stage.

End to End Project Capitalization flow Glance

The Scenario: Capitalizing Equipment Through a Capital Project

Let's use a straightforward example.

A company is acquiring equipment through an Oracle Fusion capital project.

Two expenditure types are charged to the project:

Expenditure Type	Amount
Equipment	$1,500
Fees	$500
Total Project Cost	$2,000

For this example, assume that both Equipment and Fees are eligible for capitalization according to the company's capitalization policy.

The costs are initially collected in Oracle Project Costing.

Our objective is to follow the same $2,000 from Project Costing all the way to the resulting Fixed Asset.

The high-level Oracle flow is:

Source Transactions → Project Costing → Capital Project → Project Asset → Generate Asset Lines → Assign Asset Lines → Transfer to Fixed Assets → Capitalized Asset → Depreciation

Capitalization Concepts You Actually Need

Before going through the Oracle processes, let's understand the key objects involved.

Capital Project

A capital project is used to collect costs associated with constructing, acquiring, or preparing assets for use.

In our example, the capital project collects:

Equipment — $1,500
Fees — $500
Tax - $180

This results in:

Total Project Cost = $2,180

The project provides the structure in which the costs can be collected and subsequently processed for capitalization.

Construction in Progress (CIP)

While an asset is being constructed, acquired, or prepared for use, qualifying costs can accumulate as Construction in Progress (CIP) rather than immediately becoming a depreciable fixed asset.

In our example, the qualifying $2,000 can accumulate through the capital project lifecycle until the Equipment Asset is ready to be placed in service.

This distinction is important because:

CIP represents an asset that is not yet ready for its intended use.

Once the asset is ready and capitalized, the qualifying cost can move from CIP to the appropriate Fixed Asset cost account.

Project Asset

A Project Asset represents the asset being constructed or acquired through the project.

For our example:

Project: Equipment Acquisition Project

Project Asset: Equipment_Asset_001

Conceptually:

Equipment Acquisition Project

↓

Equipment Asset

The Project Asset provides the connection between the costs accumulated in Project Costing and the asset that will ultimately be processed in Fixed Assets.

Asset Lines

Asset lines represent project costs that have been prepared for capitalization.

They provide the bridge between expenditure items in Project Costing and the Project Asset that will eventually be transferred to Fixed Assets.

For our example:

Equipment — $1,500

Fees — $500

↓

Asset Lines — $2,000

↓

Equipment Asset

Capitalization Date / In-Service Date

The capitalization timing determines when the asset moves from the acquisition or construction stage toward becoming a depreciable asset.

Once the asset is transferred, processed, and placed in service in Fixed Assets, depreciation can begin according to the applicable Fixed Assets rules.

The Oracle Process: From Project Cost to Fixed Asset

Now let's walk through the operational flow using the same $2,180 throughout the process.

Step 1 — Create and Configure the Capital Project

The process starts with a project configured for capitalization.

For our example:

Project Name: Equipment Acquisition Project

Expected Project Cost: $2,180 after tax

The project needs the appropriate project type and financial configuration to support capital asset processing.

At this stage, the capitalization-related configuration establishes the framework that allows qualifying project expenditures to eventually become fixed assets.

Think of the capital project as the container in which the asset-related costs will initially accumulate.

Step 2 — Create the Project Asset

Next, create the Project Asset representing what is being acquired.

For our example:

Project: Equipment Acquisition Project

Project Asset: Equipment Asset

The Project Asset contains information required to eventually create or update the corresponding asset in Fixed Assets.

Our structure now looks like this:

Equipment Acquisition Project

↓

Equipment Asset

Because our example contains only one Project Asset, both eligible expenditure types will ultimately be associated with the same asset.

Step 3 — Collect Project Costs

Costs can enter Oracle Project Costing from several sources, including:

Payables supplier invoices
Procurement transactions
Employee expenses
Time and Labor
Inventory
Miscellaneous transactions
Imported third-party costs

For our example, two expenditure types are collected:

Expenditure Type	Amount
Equipment	$1,500
Fees	$500
Tax	$180
Total	$2,180

Once imported and processed, these expenditure items become part of the project's actual cost.

The project now contains:

Equipment = $1,500

Fees = $500

Tax = $180

Therefore:

*Total Actual Project Cost = $2,000 and after tax $2180 *

However, this is an important distinction:

Having $2,180 of cost on a capital project does not automatically mean that a $2,180 Fixed Asset has already been created.

The costs still need to go through the capitalization lifecycle.

Step 4 — Determine Capitalizable Costs

Not every project expenditure necessarily needs to become part of a Fixed Asset.

Organizations establish capitalization policies that determine which costs qualify.

For our example:

Expenditure Type	Amount	Treatment
Equipment	$1,500	Capitalize
Fees	$500	Capitalize
Tax	$180
Total	$2,180	Capitalize

Both expenditure types qualify for capitalization.

Therefore:

Total Project Cost = $2,180

Capitalizable Cost = $2,180

Tax = $180

This is an important concept when working with Oracle Project Costing:

Project Cost does not automatically equal Fixed Asset Cost.

In our example they happen to be equal because both expenditure types are capitalizable.

In a real-world project, some expenditures may intentionally remain expenses and therefore never become part of the asset's capitalized cost.

Step 5 — Generate Asset Lines

Once eligible project costs are available, the next major processing step is to Generate Asset Lines.

This process takes qualifying project expenditure information and prepares those costs for capitalization.

Conceptually:

Project Expenditure Items → Capitalizable Costs → Generate Asset Lines → Project Asset Lines

For our example:

Equipment — $1,500

Fees — $500

↓

Generate Asset Lines

↓

Total Asset Lines — $2,180

This is one of the most important stages in the capitalization process.

Before this point, we are primarily dealing with project expenditure items.

After asset lines are generated, we are dealing with project costs that are being prepared for capitalization.

Step 6 — Assign and Review Asset Lines

Once asset lines are generated, they need to be associated with the appropriate Project Asset.

In our example, there is one Project Asset:

Equipment Asset

The generated capitalizable costs are associated with this asset:

Project Asset	Expenditure Type	Amount
Equipment Asset	Equipment	$1,500
Equipment Asset	Fees	$500
Total Tax		$180
Total Asset Cost		$2,180

Therefore:

Equipment Asset = $2,180

Before transferring anything downstream, this becomes an important validation point.

Review:

Project Asset assignment
Capitalizable amounts
Asset dates
Asset category
Asset book information
Cost allocation
Total asset cost

For our example, the reconciliation should now look like this:

Project Cost = $2,180

↓

Capitalizable Cost = $2,180

↓

Generated Asset Lines = $2,180

↓

Assigned Project Asset Cost = $2,180

Everything reconciles.

Step 7 — Transfer Asset Information to Fixed Assets

Once the asset lines are ready, the capitalization information can be transferred from Project Costing to Oracle Fixed Assets.

The conceptual flow now becomes:

Project Cost → Project Asset → Asset Lines → Transfer → Fixed Assets

Using our numbers:

$2,180 Project Cost

↓

Equipment Asset

↓

$2,180 Asset Lines

↓

Transfer to Fixed Assets

↓

$2,180 Asset Cost

This is the point where Project Costing effectively hands the capitalization transaction over to the Fixed Assets module.

It also represents an important shift in responsibility.

Project Costing determines and prepares the project cost being capitalized.

Fixed Assets manages the resulting asset through its asset lifecycle.

After Asset is being successfully transferred to Fixed Assets Module

Step 8 — Process the Asset in Fixed Assets

Once transferred, the asset information is processed on the Fixed Assets side.

Fixed Assets uses the transferred information along with its own configuration, including attributes such as:

Asset category
Asset book
Asset cost
Date placed in service
Depreciation method
Useful life
Depreciation convention
Asset accounts

Our example ultimately produces:

Asset: Equipment Asset

Capitalized Cost: $2,180

Asset Category: Equipment

In projects run the program "Update the Asset information from fusion assets" in order to update the asset number details from FA to Projects

The Project Costing-to-Fixed Assets flow highlights how Oracle Fusion seamlessly connects project expenditures with asset capitalization. Once you understand how costs move through Project Costing → Project Assets → Asset Lines → Fixed Assets, the entire capitalization lifecycle becomes much easier to manage and troubleshoot.

Have questions about Project Asset Capitalization in Oracle Fusion? Drop a comment below or connect with me through the Oracle ACE community. I’d love to hear about your implementation experiences.