Date: Fri, 29 Mar 2024 08:40:20 -0500 (CDT) Message-ID: <1175797645.30388.1711719620578@PUBEDFIPRDWEB5.public.local> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_30387_761471351.1711719620577" ------=_Part_30387_761471351.1711719620577 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Ed-Fi Request for Comment 18: FINANCE API
Product: Ed-Fi Data Standard v3.1
Affects: Ed-Fi ODS / API
Obsoletes: --
Obsoleted By: --
Status: Active
Ed-Fi Alliance
June 28, 2019
The Finance API describes an API surface for the exchange of K=E2=80=931= 2 education organization finance data. The API exchanges charts of accounts= , their mappings, and budget and actuals for those accounts.
The API is designed to support many use cases related to exchange of fin= ancial data. The API design specifically includes the data models, transact= ional surface, and other structures necessary to support the federally mand= ated Every Student Succeeds Act (ESSA) financial transparency reporting.
Contents
The Finance API specification provides a blueprint for capture, exchange= and validation of financial data for K=E2=80=9312 education organizations.= The Ed-Fi Alliance Finance domain has been expanded with this API specific= ation to align with state and local accounting practices, and to accommodat= e new transparency reporting requirements from the federally mandated Every= Student Succeeds Act (ESSA).
The current Ed-Fi Data St= andard v3.1 Finance domain model provides a link between accounts and e= ducation organizations such as State Education Agencies (SEAs), Local Educa= tion Agencies (LEAs), Charter Management Organizations (CMOs), and Schools.=
The Ed-Fi Finance Work Group has compiled feedback from the Ed-Fi Commun= ity to define use cases not supported by the current finance domain model. = The proposed Finance API model would allow for mapping data to report an LE= A set of accounts to an SEA=E2=80=99s Chart of Accounts. The Finance API in= cludes the ability to guarantee the integrity of full account codes and to = tag budgeted and actual amounts to specific required reporting submissions.=
The proposed Finance API is aligned with common accounting standards and= reporting standards in the K=E2=80=9312 education space. The primary sourc= es include:
The sources above build upon the Generally Accepted Accounting Principle= s (GAAP) as established by the Governmental Accounting Standards Board (GAS= B).
The architecture covered by this model of data exchange is intended to s= erve the following SEA, LEA, and CMO use cases.
The SEA use cases center on data exchange with LEAs related to state and= federal finance reporting requirements. These use cases include:
ESSA (or other) financial reporting by a district can be generated by an= SEA. The SEA maps the state-level COA to the various categories used for E= SSA reporting, identifying the various dimensions and/or granular COA accou= nts for each ESSA category. The SEA and LEAs review the data for correctnes= s and approve the data. The SEA publishes the ESSA reports to the public.= p>
The same general use cases are applicable for charter management organiz= ations to receive financial budgets and actuals from the schools in their n= etwork.
In regions where there is no Finance API at the state level, an LEA may = find the Finance API useful for its own purposes. For example, an LEA can l= oad the SEA-defined COA into a backing datastore, map its own local account= codes, and directly generate reports for the SEA. The data exchanged via a= Finance API also supports an LEA=E2=80=99s analytics and reporting (e.g., = to link financial data with student outcomes and school operations informat= ion).
The Ed-Fi Unifying Data Model (UDM) harmonizes data definitions across t= echnology published by the Ed-Fi Alliance. This section describes the Ed-Fi= UDM structure for the proposed Finance API.
Figure 1. Ed-Fi F= inance domain representation
The Chart of Accounts entity forms the backbone for classifying expendit= ures of all types. Each Account Identifier element is comprised of a compou= nd structure of multiple types of classifications, or dimensions, = each with a hierarchical code structure. Example dimensions include:
While different states use different sets of dimensions, many are standa= rdized in the financial accounting standards published by the NCES. By conv= ention, each dimension of an Account Identifier has a dimension code reflec= ting a hierarchical organization. For example, a dimension Code of 100 is t= ypically a roll-up of 110, 120, 130, =E2=80=A6, and a dimension Code of 120= is a roll-up of 121, 122, 123, =E2=80=A6, and so forth.
In the data model, there are enti= ties for each dimension whose values define the set of allowable numbers wi= thin the dimension. The Chart of Accounts entity holds the set of valid com= pound account codes, each linked to their requisite dimensions' code. While= this may seem duplicative, each aspect has a specific purpose in that the dimension entities enumerated= in the model reflect the national standards. The dimension entities provid= e a convenient mechanism for query, reporting, and roll-ups along dimension= al lines.
Though not part of this specifica= tion, API platform hosts could define additional dimensions by repeating th= is convention.
Because all combinations of dimen= sion code values are not valid, the Chart of Accounts entity delineates the= set of valid compound account codes. The mapping (i.e., the association) o= f Local Accounts (including the Budget and Actual entities) to the Chart of= Accounts will allow the API to ensure that only valid Chart of Account ent= ities are referenced. This validation is typically performed by refere= ntial integrity checks in an underlying platform's datastore. This approach= obviates the need for dozens of business rules to check for valid combinat= ions had a dimension-only model has been used. The Chart of Accounts entity= provides the definitive list of account codes used to derive accounting st= atements and to produce budget versus actual reports.
This section provides a few example usage patterns for the Finance API.<= /p>
SEA client systems will create a chart of accounts through the /ch=
artOfAccounts
endpoint. Each POST to /chartOfAccounts
i=
s analogous to creating a row in a typical chart of accounts spreadsheet, a=
nd contains similar information: a name and code for the account, plus acco=
unting dimension information such as the type of account (e.g., expense), t=
he fund type (e.g., general fund, capital project fund), the object of the =
account (e.g., salaries, technical services, utility services), and so fort=
h.
The example listing below illustrates the information sent for a hypothe=
tical instructional fund expense (10 in the fundDimensionReference) related to teacher salaries (100 in the
objectDimensionReferenc=
e
) in the regular curriculum (120000 in the functionDimensionR=
eference
):
{ "id": "58aa05e44e4e4d709d3d491241f30386", "accountIdentifier": "10-100-120000", =09"fiscalYear": 2020, "educationOrganizationReference": { "educationOrganizationId": 1 }, "functionDimensionReference": { "code": "120000", "fiscalYear": 2020 }, "fundDimensionReference": { "code": "10", "fiscalYear": 2020 }, "objectDimensionReference": { "code": "100", "fiscalYear": 2020 }, "accountName": "Salaries", "accountTypeDescriptor": "uri://state-agency-example.edu#Expense", "reportingTags": [ { "reportingTagDescriptor": "uri://state-agency-example.edu#ESSA" }, { "reportingTagDescriptor": "uri://state-agency-example.edu#Statewide= -Report-Fall-2020" } ] }
In this example, the SEA has reflected the dimensions in the accou=
ntIdentifier
(10-100-120000). But, the API doesn't require or enforc=
e that pattern, so SEAs may use any identification scheme that works for th=
eir environment.
In most state education systems, the SEA will issue an authoritative cha=
rt of accounts. Local education agencies and charter management organizatio=
ns are required to map their local accounts to the SEA chart of accounts. L=
ocal accounts are often finer-grained classifications within the SEA accoun=
ts, but may also be additive. In addition, the SEA often has accounts that =
are not used at the local level. The LEAs and CMOs are typically responsibl=
e for mapping local accounts to the authoritative SEA chart of accounts. In=
the Finance API, this is done through the /localAccounts
endp=
oint.
Building on the example above, the following listing shows a hypothetica= l school district's mapping to an SEA's account for teacher salaries. In th= is example, the LEA is mapping its fine-grained account for Language Arts -= Literature teacher salaries to the SEA's more general account for regular = curriculum teacher salaries.
{ "id": "336108d6468f43408388221bde5c639c", "accountIdentifier": "LEA16-10-100-122300", "chartOfAccountReference": { "accountIdentifier": "10-100-120000", "educationOrganizationId": 1, "fiscalYear": 2020 }, "educationOrganizationReference": { "educationOrganizationId": 16 }, "accountName": "Regular Curriculum - Language Arts - Literature", "reportingTags": [ { "reportingTagDescriptor": "uri://state-agency-example.edu#LEA-Super= intendent-Report" } ] }
Items of note from this example:
chartOfAccountReference
from the LEA. =
This ensures every LEA account maps to exactly one SEA account.The Finance API specification allows client applications to read and wri= te finance data through a secure REST interface.
API implementers and client system developers are expected to follow all= guidelines in the Ed-Fi API Design and Imp= lementation Guidelines. These include requirements relating to errors, = authentication, security, and other aspects of API usage and implementation= . Any MUST requirements from that document are considered necessary to conf= orm to this specification. If there are differences between the requirement= s included in this document and the Guidelines, the information provided in= this document has precedence.
An OpenAPI definition of the proposed Finance API interface is provided = below. Consume= r implementations wishing to conform to this standard are expected to imple= ment paths, resources, and definitions as described in that OpenAPI specifi= cation. In addition, providers must accurately follow other related semanti= cs defined in the Ed-Fi UDM (for example, for references to entities outsid= e this domain).
The following is a summary of paths in the Finance API and brief descrip= tions:
The set of account codes defined by an education organization for a fisc= al year. Provides a formal record of the debits and credits relating to the= specific account.
The set of local education agency or charter management organization bud= get amounts.
The set of local education agency or charter management organization act= ual financial result amounts, typically based on the accrual basis of accou= nting.
A valid combination of account dimensions under which financials are rep= orted. This financial entity represents a funding category combined with it= s purpose and type of transaction. It provides a formal way to categorize t= he debits and credits relating to a specific account.
The NCES fund accounting dimension. A fund is defined by the NCES a= s "a fiscal and accounting entity with a self-balancing set of accounts rec= ording cash and other financial resources, together with all related liabil= ities and residual equities or balances, and changes therein, which are seg= regated for the purpose of carrying on specific activities or attaining cer= tain objectives in accordance with special regulations, restrictions, or li= mitations." Most SEAs use a similar definition.
The NCES program accounting dimension. A program is defined by the NCES = as "a plan of activities and procedures designed to accomplish a predetermi= ned objective or set of objectives." These are often categorized into broad= program areas such as regular education, special education, vocational edu= cation, other PK-12 instructional, nonpublic school, adult and continuing e= ducation, community and junior college education, community services, and c= o-curricular or extracurricular activities. Most SEAs use a similar de= finition.
The NCES function accounting dimension representing an expenditure. Per = the NCES definition, the function describes the activity for which a servic= e or material object is acquired. The functions of a school district are ge= nerally classified into five broad areas, including instruction, support se= rvices, operation of non-instructional services, facilities acquisition and= construction, and debt service. Functions are typically further classified= into sub-functions. Most SEAs use a similar definition.
The NCES object accounting dimension representing an expenditure. Per th= e NCES definition, this classificati= on is used to describe the service or commodity obtained as the result of a= specific expenditure, such as salaries, benefits, tuition reim= bursement, and so forth. Most SEAs use a similar definition.
The NCES project accounting dimension. Per the NCES, the project dimensi= on reporting code permits school districts to accumulate expenditures to me= et a variety of specialized reporting requirements at the local, state, and= federal levels. In the NCES reporting scheme, this is typically a three-di= git code with the format 00X. The first two digits identify the particular = funding source, authority, or expenditure purpose for which a special recor= d or report is required. The third digit is available to identify particula= r projects and the fiscal year of the appropriation within that funding sou= rce. SEAs will typically provide guidance to LEAs on how to structure this = code.
The NCES operational unit accounting dimension. Per the NCES, this = dimension is used to segregate costs by school and operational unit such as= physical location, department, or other method. SEAs may provide guidance = to LEAS on how to structure this code, or it may be at the discretion of th= e local organizations.
The NCES source dimension. Per the NCES, the source dimension is us= ed to classify revenue, receivables, and other sources of income based on t= heir origins such as taxes, tuition, fees, and so forth. Revenue increases = both the assets and the equity of a local education agency or charter manag= ement organization as a whole. Most SEAs use a similar definition.
The NCES balance sheet accounting dimension. The NCES definition states = that the balance sheet accounts and statement of net position accounts are = used to track financial transactions for each fund. Such financial statemen= ts only report assets, deferred outflows of resources, liabilities, deferre= d inflows of resources, and equity accounts. The statements are considered = "snapshots" of how these accounts stand as of a certain point in time.
Technical definitions of these paths can be found in the Finance API OpenAPI specification= .
Initial review of the Finance API specification has raised the following= questions and comments.
The questions posed here are entirely around whether the Finance API spe= cified in this RFC 18 has a role in supporting these processes or communica= ting information between different systems related to these processes. = ;The concerns raised in this section may be entirely addressed by existing = client system functionality and/or business processes. If that's the case, = then no action is indicated.
We welcome responses to issues raised in the Key Questions above, and co= mments on any part of the model. The primary mechanism for feedback is via the Ed-Fi Alliance general proj= ect in the Ed-Fi Tracker.