Per SIS Integration Notes

The Housing.Cloud integration works the same way for everyone — this article covers the thin layer that differs by student information system. Find your SIS below. Read it alongside How Housing.Cloud Works and the CSV Schema articles. These notes are not meant to be exhaustive, as each system has it's own standards and configurations per institution that may differ.

Ellucian Colleague

• Three code types are genuinely distinct here: AR code ≠ charge code ≠ room-rate code. Charges post as AR invoices. The room-rate table and AR mapping are not 1:1 — confirm the mapping deliberately.
• If connecting via Ethos: indexing must complete before any egress; expect caching lag (config changes can take minutes up to ~24h), and a first API call after idle may time out (app-pool warm-up).
• Known Ellucian bug: an end date on an active room-rate table breaks the rate match via Ethos. Leave end dates blank on rate tables used for current terms.
• Billing option: some Colleague schools let Colleague generate charges in batch from the rate code (occupancy-only feed) rather than consuming a transaction file — decide which model you're using.

Ethos is Ellucian-only; see Ethos Enablement.

Ellucian Banner

• Term codes are 6-digit (e.g. 202610); a YYYY90-style variant also appears — confirm your exact format.
• Application statuses must map through Banner's housing tables; occupancy statuses often collapse to active/inactive. Status mapping page: SLRMSCD.
• Loading pattern: most Banner teams load the file into a temp table and pull the max occupancy ID to resolve current state (a same-day cancel + reassign share a date — sort by occupancy ID, not date).
• Date of birth may arrive with a timestamp; adjust the format on your side. Watch for hidden characters in Banner-sourced exports.
• Duplicate IDs sometimes carry an X suffix; admit-code filtering (e.g. Aa/Cc) may be needed.
• If connecting via Ethos: Banner needs the extra housing-requests / meal-plan-requests calls and GORICCR override = Y; room rate is required even for a flat rate. See Ethos Enablement.
• File movement: some campuses use Control-M jobs against an S3 bucket rather than a direct SFTP client — fully supported.

PeopleSoft (Campus Solutions)

• Debits and credits: Housing.Cloud sends one transaction file (flagged by isRefund); PeopleSoft shops typically split it into two for group post. Plan that transform on your side.
• Item types: the posting target is the PeopleSoft item type, which lives in a specific field — not the visible code. Item-type prefixes (e.g. 8xx/801) route to the right ledger.
• Term codes: use the true PeopleSoft term code, not a legacy value carried over from a prior system.
• Encryption: PGP is a common PeopleSoft-shop standard. Confirm with your Specialist before assuming it's in place — it is not part of the standard SFTP setup.
• Student ID is typically the CWID.

Workday Student

• Detail codes don't survive — Workday consumes description-only, so encode what you need in the transaction description.
• ID placement: the student ID (CWID) must be the first column; reference IDs use underscores.
• Meal plans may split into block/flex.
• Housing.Cloud is typically the book of record feeding Workday, often through middleware (e.g. Alchemy). Go-live is gated by the Workday project timeline — plan the dependency.

Anthology Student

• The native housing/billing module is limited — many schools bypass it and bill off the Housing.Cloud feed.
• Billing model varies: some schools bill implicitly off the occupancy file (no transaction file consumed); others use pending charges + Transact. Decide which.
• Forms Builder / Engage may coexist with Housing.Cloud forms — clarify ownership.
• Door access is often Atrium.
• Watch for parallel projects (e.g. a Pathify SFTP effort) and Ellucian consultants who may need KB access.

Don't see your SIS?

SFTP and the Public APIs work with any SIS — the core articles apply as-is. Flag your SIS to your Integrations Specialist and we'll note any specifics.