Reviewing AP Invoices for Correct Income Tax Types
Nancy T. Williams, Senior Programmer Analyst
Rikki Venne, Functional Systems Accountant
Loudoun County Government
703-771-5262 [email protected]
703-771-5715 [email protected]
May 2 - 3, 2019
About Loudoun County Founded in 1757
Located in northern Virginia
Part of the DC–VA–MD–WV Metropolitan Statistical Area
Almost 6000 employees working for the County Government
Estimated 2018 population is 402,561; 2010 census was 312,311
Serve over 82,400 students in 92 public schools
Went live with Oracle Financials in 2013 and HCM in 2017
Modules used by County and LCPS employees: PO, AP, AR, GL, iSupplier, Cash Mgmt, iExpense, HR, SSHR, OAB, Payroll, OTL, OLM, OAM, and iRecruitment
2
Problem In Oracle, the income tax type is set at the supplier level not the object level.
This is problematic because we have a multi-org business structure and share supplier data with our school system. Excluding employees, we have over 17,000 suppliers.
We operate as a decentralized payables department with over 400 users.
Even with custom reports, our end of year 1099 process still required a manual review of around 100,000 invoices to ensure proper income tax type coding.
We needed a way to determine the correct income tax type based on the invoice expense rather than the tax type assigned to the supplier.
We explored several options and ultimately decided we needed to be able to programmatically override the defaulted supplier income tax type with an income tax type based on the expense type.
3
Solution Created an Excel spreadsheet using our chart of accounts and assigned
an income tax type to each object code based on the expense type.
4
Solution (continued) Modified the file to have just two columns, Object and 1099
Type, and saved as a csv file so it could be uploaded to Oracle using a customized sql loader concurrent program.
5
Solution (continued) Created an Oracle validation table to hold the data from the csv
file, i.e., each object code and its corresponding income tax type.
CREATE TABLE LCAP_COA_1099TYPE_VAL
( OBJECT_CODE NUMBER(6),
TAX_TYPE_1099 VARCHAR2(15)
);
6
Solution (continued) Created two control files (one for the initial load using an INSERT
and one for subsequent uploads using a REPLACE) to use with our sql loader concurrent program to upload the csv data file containing the object code and income tax type into the custom validation table created in step 3.
options(skip = 1)
LOAD DATA
INFILE *
INSERT INTO TABLE LCAP_COA_1099TYPE_VAL
FIELDS TERMINATED BY ','
OPTIONALLY ENCLOSED BY '"'
TRAILING NULLCOLS
( OBJECT_CODE "TRIM(:OBJECT_CODE)",
TAX_TYPE_1099 "TRIM(:TAX_TYPE_1099)"
)
7
Substitute REPLACE for INSERT for subsequent uploads of data to the validation table
Solution (continued)
Modified the AP_CUSTOM_INV_VALIDATION_PKG to update each incorrectly coded AP invoice during the invoice validation process to the correct income tax type based on the invoice’s object code in the accounting string and the corresponding income tax type in the new table. The distribution level income tax types on the invoice workbench will display the updated values.
8
What Happens if the CoA Changes?
As object codes are added, deleted, or modified in our chart of accounts, the AP staff will maintain the Excel spreadsheet which matches each object code to the proper 1099 type.
AP staff will then upload the new spreadsheet as needed using our customized sql loader concurrent program and the “REPLACE” control file.
9
Updating Validation Table for CoA Changes Use Replace Control File
We needed to test that the updates to the newly created validation table would override the existing data in the table.
10
Test 1 Direct Pay Null Tax Type
We used a vendor who did not have a designated income tax type on the supplier record and created a direct pay invoice with several lines with different object codes.
11
The distributions screen shows the income tax type defaulted from the supplier record to null.
Test 1 Direct Pay Null Tax Type
After validation, the income tax types have been updated to the correct values on the distributions screen based on the object code in the accounting string.
12
Test 2 Direct Pay with a Default Tax Type
Next, we used a vendor who does have a designated income tax type on the supplier record and created a direct pay invoice using several different object codes. After validation, the correct income tax types should be shown at the distribution level regardless of the designated income tax type on the supplier record.
13
Test 2 Direct Pay with a Default Tax Type
Pre-validation, the distributions screen shows the income tax type defaulted from the supplier record as MISC1.
14
Test 2 Direct Pay with a Default Tax Type
Validate the invoice. The income tax types have been updated to the correct values on the distributions screen.
15
Test 3 Custom Payables Interfaces Income tax type on the supplier record is MISC7
Data file to be imported shows tax type as “None”:
Validation table has an income tax type of None for object code 63554 which is the object code in the data file shown above.
16
Test 3 Custom Payables Interfaces
Import of the data file created an invoice with income tax type MISC7 on the distributions screen because that is the designated value on the supplier record.
17
Test 3 Custom Payables Interfaces
After validation, the income tax types have been updated to the correct null values on the distributions screen.
18
Test 4
Redistributions
A redistribution was done at the distribution level on an a paid invoice. Shown here before validation.
19
Test 4 Redistributions
After validation, the income tax types have been updated to reflect the correct tax type on the distribution screen.
20
Savings We estimate this will save the County over 100 hours in
collective review time each year
The time reduction translates to over $10,000 in annual savings
By drastically reducing the amount of manual entry and updates we are further preventing erroneous reporting that could result in improper filing and/or IRS fines
21
Questions?
22
Top Related