Project Costing rejects expenditure items that fail validation against the project, task, expenditure type and date rules. Costs from Payables, Payroll and Inventory transfer into projects through interface processes, and each has its own rejection reasons. Project-to-GL differences almost always mean costs were captured in projects but not yet accounted, or accounted in a different period.
What problem does this solve?
Rejected expenditure items usually fail on the project or task being closed, an expenditure type not permitted for that project, or a date outside the project or task effective dates.
Costs not transferring from Payables is the second pattern: the invoice distribution was not flagged for projects, or the transfer process has not run since the invoice was accounted.
Project-to-GL differences are typically timing rather than error — costs collected in projects but not yet accounted, or accounted into a period that has since closed.
How the solution works
We work the transfer chain in order — source transaction, interface, project cost, accounting — because a difference at the end is almost always explained by an incomplete step earlier.
Rejections are corrected at the source distribution where possible, so the same transaction does not reject again on the next run.
- 1Identify which validation failed for each rejected expenditure item.
- 2Confirm the expenditure date falls within the project and task effective dates and that neither is closed.
- 3Confirm the expenditure type is permitted for the project type and the transaction source.
- 4Confirm the process moving costs from Payables, Payroll or Inventory has run since the source was accounted.
- 5Generate and transfer project accounting before comparing project balances to the ledger.
- 6Compare project and GL balances for the same accounting period, not across periods.
Limitations & prerequisites
- Reopening a closed project or task to accept a late cost has reporting consequences and may require approval outside the finance team.
- Costs rejected and left uncorrected accumulate silently; there is no automatic escalation, so the queue needs an owner.
- Project-to-GL reconciliation is only meaningful for the same period; comparing across periods produces differences that look like errors but are timing.
- Where labour costs come from payroll, correction depends on the payroll cycle and cannot always be resolved within the current period.
- Capitalisation rules and asset assignment add a further stage where costs can stall after successfully reaching the project.
FAQ
Most often the project or task is closed, the expenditure date sits outside the project or task effective dates, or the expenditure type is not permitted for that project type. The rejection record names the validation that failed.
Either the invoice distribution was not marked for projects, or the transfer process has not run since the invoice was accounted. Confirm the accounting completed first — costs cannot transfer from an unaccounted invoice.
Usually timing. Costs are collected in projects but not yet accounted, or were accounted into a different period. Reconcile the same period on both sides before treating it as an error.
Not without reopening it, which is a controlled action with reporting implications. Where late costs are routine, the project closure process itself is worth reviewing.
They transfer on the payroll cycle, so corrections follow that cycle rather than the finance close. Where a labour cost is wrong, it usually cannot be fixed within the current period, and that constraint should be understood before committing to a close date.
They stay rejected. Project costs remain understated, capitalisation may be incomplete, and the difference surfaces at project close or year end. The rejection queue needs a named owner and a review cadence.
Tell us the module, the release and the exact symptom.
Send the module in scope, your Fusion release or EBS version, and the exact error text or symptom with a screenshot where you have one. We reply with a written assessment: the likely cause, what we would check first, and whether it is a configuration fix, a data fix, or a defect that needs an Oracle service request. When Swedish Technology can help, we scope the remediation with effort and sequence before you commit to anything.
Request an Oracle AssessmentSources & evidence
- Oracle Help Center — Cloud Applications documentation — module setup, subledger accounting and period-close reference
- Oracle Help Center — all product documentation — database, middleware and infrastructure reference used for error diagnosis
- My Oracle Support — patches, known-issue notes and service requests; Oracle account required
Vendor and product names are trademarks of their respective owners; references are for technical context and do not imply partnership, certification or endorsement unless stated on the vendor's official pages.