KFS General Ledger Feeder System Requirements

The Accounting office must approve of all file feeds to KFS before such files are sent to the production environment, to ensure they comply with University processes, General Ledger posting standards, and general user experience in regards to reconciliations/audit.  This includes upgrades to existing feeder systems, as well as new ones.   The Accounting Office/Controller’s Office may sign off on the initial go-live feed, but each feeder system will need continued management of their General Ledger feeds by technical and functional entities in the unit.  This is in order to ensure their files contain active data and valid entry combinations, before attempting each feed to the KFS General Ledger.  

Attributes & Approvals

• A feeder system needs to work with all KFS General Ledger (GL) attributes.  The feed to the GL should have the capability to have the Full Accounting Unit (FAU).   Workflow/approvals should also be recorded and tracked within the feeder system.  Additionally, if any security or ‘access roles’ need to be input in the vendor system, that access roles can utilize the KFS Organization hierarchy structure and/or utilize KSAMS to create/maintain access and roles.
  • Only certain users should be allowed to create/change billing information for specific organizations or purposes.  Workflow/approvals should be achieved on the front-end in the feeder system, so that billing requests are funneled to an appropriate financial manager.  Alternately, the feeder system should give Fiscal Officers a certain amount of time to review billing requests, before it is fed to the GL.

Controls & Rules

• Each feeder system function should have a separate Origin Code.  For upgrades, the same Origin Code may be used, if desired.  For new systems, this can be established by notifying Accounting and KFS teams.  The Origin code allows for different categories/types of feeder systems, different information to go into the feeds, and possibility of different mapping to redirect department users back to the source system.
• Journals should be balanced (debits equal credits).   All recharges to a department should be offset by income/credit to the billing agency.  If a file feed is not balanced, the assumption is that the file or a transaction should fail and require further review/edit before re-feeding.  The feeder systems will need to discuss with their Project Manager or Technical Team how file edits can occur.
• Charges need to be ‘collapsed’ and data summarized at the appropriate level (ex: Ordering 10 computers on the same FAU should just have one summarized charge for the total, rather than individual entries per computer )
• The feeder system should allow departments to input and feed over the complete General Ledger FAU possibilities. The ability to allow department personnel to input Chart/Account, Sub-Account, Object Code (or have it pre-determined), Sub-Object, and Project Code is required to go live initially, since it is the core of the FAU.  All of these fields require validation/pre-existing entries in KFS, though some fields will be optional to departments to input.  Additional fields like Organization Document Number and Organization Reference ID are considered best-practice to have upon going live with a system, to allow department initiators to fill in their own tracking numbers.  These two latter fields are free-fill and no validation needs to occur.
  • Detailed information on all KFS General Ledger fields is in the below chart.
• The system should be able to feed in credits (for error correction or past-feed overcharges etc.).  Otherwise, the feeder department will need to work out a plan in advance for errors that would be one-off, as this might require the billing/feeder department to do individual GECs.
• The system should handle split-funding.  This includes split charges between two accounts, and also splits between different FAUs (like everything is the same account, but different project codes, which counts as being split-funded)
• Each new feeder system and any upgrades or changes must be thoroughly tested by the feeder’s functional unit in conjunction with KFS (for billing).
• The feeder system will need to provide their own training and helpdesk functionality if a user has questions on their ledger charges (which means functional contacts and technical contacts will be needed by the KFS Helpdesk to refer users to).  If the feeder system has a billing limitation (they cannot accommodate the KFS FAU for example) then the feeder system will need to communicate this in training to users, and have a resource for department financial reconcilers.

Feed Validations

• Certain attributes of the Accounting Line must exist in KFS first, and be valid/active, before they can be fed over to the ledger.  More details on all attributes are given in the chart below.
• Ideally, validation of FAU would be upon initial entry into the vendor’s system, as well as before being fed into KFS.  This can be accomplished by web service calls by the API.  This form of double-checking ensures possible errors are caught if there have been updates/changes during the time of the feeder system request (like for a work order) up until the time when the request is processed and billed
  • Trying to feed invalid date over to KFS will cause a file failure.  Discussions need to be done by the Technical host on whether the whole file should fail, if one entry creates an error, or if the ‘failure’ can go to a default account/object (that belongs to the feeder system’s Organization) that must be reconciled/corrected by the feeder department
• For stored FAUs in a feeder system, validation should be done periodically with departments to ensure no changes need to take place.  This can be either a manual process to contact a department’s financial user, or periodic web service calls to the API.
• KFS has Object Code restrictions for all feeder systems, especially for those that feed income and expense recharges.  (ex: Non Payroll feeder systems cannot feed payroll object codes, and no feeder system may use budget object codes)   Each feeder system will have to work with Accounting and a KFS representative to discuss what object codes will be used in their feeder system upfront.  KFS will implement OOE rules for feeder systems so that if the wrong combination of Account or Object Code is attempted to feed to the Collector, a transaction error will kick out (for further review/edits).

Drill-Down Reconciling & Retention

• Ideally, there should be a way to tie the entry back to a singular record or a singular source in the Feeder.  This is to enable departments quick and easy access when reconciling ledgers and verifying charges for accuracy.
  • There needs to be a training/FAQ/guide from the Feeder Department in order to guide users how to map charges on a ledger back to the source system or a secondary reporting system (part of department ledger reconciling).
  • If the source system can be mapped back to easily via hyperlinks, the Feeder system can work with the KFS/UCI Decision Support Team to ensure mapping occurs on by providing links on the General Ledger, based on the fed ‘document number’.
• A retention plan for ‘backup details’ is critical for Feeder Systems to discuss when working with a vendor.   Financial System users and departments are required to keep backup detail records, from ledger charges, for a specified period of time.  How long, depends on their funding source.  
  • Departments are the office of record for backup/details on ledger charges.
    • However, many departments will elect not to print or store ‘backup’ reports if it is accessible long-term in a feeder system via lookup.
    • Essentially, the feeder system should try to notify departments of their minimum retention plan for backup (work orders, invoices, reports, etc.) and how long it will be accessible via the feeder system’s user interface.   This gives department users an idea of how long old information will be accessible, so they can determine what needs to be printed and when.

Month End/Fiscal Year End (setting up a feed calendar)

• Systems that bill in arrears (like at month end) may not have all monthly charges summarized and available by the last day of the month.   They need to find a way to ‘post back’ the identified feed.  This includes selecting the current and open Fiscal Period and Fiscal Year.   The KFS General Ledger is open for feeder systems to post to the GL for up to 5 working days after the previous month ends.
  • Each feeder system should have a plan/schedule in place to ensure their feeds post to the correct Fiscal Period/Fiscal Year, to ensure that period is open in KFS
  • For Fiscal Year End, the feeder system cutoff will change each year, but should be during the first week of July.  The Fiscal Year End feeder system cutoff is determined by central Accounting in accordance with UCOP deadlines.  Each feeder will be warned in advance of the cutoff deadline to feed to the last ‘month’ of the year (June).