What you need before you start:

To use the Hub Testing Integration System (HITS), you'll need the following:

You'll also need a basic knowledge of SIF REST:

You need to know how to work with a use case in HITS and access the HITS API

If you get stuck: drop us a line at

How to implement financial processing

1. What's the business problem?

Allow schools to carry out financial transactions using draft SIF Financial objects, including purchase orders, receipts, invoices, journalling, and payments. More...

2. Use case description & pre-conditions

A 3rd Party Finance application connects to HITS as a jurisdiction hub, collecting the relevant information and publishing back finances records to the centralised system.

Finances conceptual model

The following diagram gives some wider context around school-level interactions for this use case. Note that some possible interactions shown here may not be covered within this technical use case.

Finances data flow

This diagram show the data flows for finances bewteen student, school and vendors.


3rd Party Vendor is a current supplier of a Finances product in schools or has knowledge of finances reporting processes in K-12 Schools.


3. Use Case Workflow

Workflow summary:

3.1. Join

3.2. Consume

3.3. Process

3.4. Provide

3.5. Assurance

3.1. Join school zone


3.2. Consume base data from HITS

Vendor-facing (pull); HITS represents the Jurisdiction and is the data source for seed information.

(The following is a list of calls that need to be made to consume the required information)

  1. Get FinancialAccount: http://.../FinancialAccounts
  2. Get VendorInfo: http://.../VendorInfos
  3. Get Debtor: http://.../Debtors
  4. Get ChargedLocationInfo: http://.../ChargedLocationInfos
  5. Get StaffPersonal: http://.../StaffPersonals
  6. Get StudentContactPersonal: http://.../StudentContactPersonals

Endpoints may support additional queries for retrieving data - refer to Query-by-example or service paths for HITS guidance on queries.

3.3. Process in 3rd Party Application

3rd Party App uses the consumed data to generate appropriate transaction information. The definition and automation of this process is out of scope of HITs.


3.4. Provide authoritative data**

Prior to providing:

Third party expresses return information in SIF/XML:

3.5. Self – confirm use case support

  1. Validate Invoice records
  2. Validate PaymentReceipts records
  3. Validate PurchaseOrder records
  4. Validate Journal records

The SIF/XML data sent by the 3rd Party app to the Jurisdiction Zone for the app must satisfy the following conditions: - Any SIF object published by the App must be valid against the SIF-AU 3.4 schema - All mandatory elements of the submitted SIF objects are provided - All SIF objects posted by the App must have referential integrity. Any RefId contained in the SIF object must refer to a SIF object provisioned to the App—e.g. AccountingPeriod, FinancialAccount—or to another SIF object posted by the App (e.g. Payment referring to Billing).This condition applies recursively to all additional SIF objects posted by the App. The test of this condition is done only when the App indicates that it has finished publishing to the Zone the objects required for the test.


More information

What business problem does this use case address?

In brief:

This use case responds to the growing interest in using SIF AU to exchange financial data. Anyone seeking to engage with this use case is encouraged to familiarise themselves with the proposed SIF AU financials objects.

This use case assumes that SIF is required only to exchange information about individual transactions (e.g. purchase orders, invoices, receipts, journals), and that reporting will be done out of existing applications—although those reports may be based on the transactional information received through SIF. 

This use case assumes that payroll transactions are out of scope; payroll has not been modelled in SIF-AU as of this writing.

This use case presupposes that there are processes in place for transactions to take place with external parties (debtors and creditors); it does not specify any mechanisms outside of SIF. A purchase order for example may be transmitted to a vendor as a SIF Purchasing object, or as a printed document drawing on information included in the SIF Purchasing object. The mechanisms for generating and sending such a printed document are outside the scope of this use case, and would be provided by existing financial applications. 

The following lists the priority areas of interest in finance (numbers in parentheses refer to the diagrams below) :

  1. Receipting – the ability to produce receipts for (1a) Families/ Debtors and (1b) General Ledgers.
  2. Purchase Orders – the ability to (2a) produce commitments into ledgers for purchases and (2b) send these to creditors as an approval method for purchases. Ability to (2c) draw down the purchase order at time of payment, to enable the commitment to be used.
  3. Invoices – The ability to produce invoice for Debtors, recovery of hire costs in particular.
  4. Entering invoices into the system to get these approved before the payment is produced and sent off.
  5. Payments – ability to produce a file to be imported into the bank; most payments are made through EFT, but departments need to be able to produce cheques also.
  6. Ability to run an end of period process including (6a) a bank reconciliation and (6b) produce reports that go to the Principal, school board, that provides the basis of producing the monthly BAS, and that gives reports to various teachers, faculty or as requested.
  7. Ability to run end of year, as schools operate on a calendar year rather than financial year.
  8. Ability to do (8a) journals to correct ledger errors, GST errors; (8b) ability to make adjustments to the schools budget; (8c) ability produce the schools budget prior to presentation and approval of the budget.

The following three workflows are SIF-based exchanges which realise most of these priority areas:

The following two workflows represent reporting processes which do not require SIF support, as they are already internally to common financial applications:

Use case preconditions for assurance


Relevant Service Paths Supported on HITS

Relevant Queries By Example Supported on HITS



  <ClassType>{type}</ClassType> <!-- TBD -->


  <BilledEntity SIF_RefObject="{objectclass}/>